Главная страница
Навигация по странице:

Лекции по Базам данных. Лекция 2 Введение в базы данных 2 2 лекция 4 Двухуровневое представление информации в интегрированных базах данных. 4



Скачать 26.66 Kb.
Название Лекция 2 Введение в базы данных 2 2 лекция 4 Двухуровневое представление информации в интегрированных базах данных. 4
Анкор Лекции по Базам данных.docx
Дата 30.04.2017
Размер 26.66 Kb.
Формат файла docx
Имя файла Лекции по Базам данных.docx
Тип Лекция
#4995

Оглавление


1 лекция 2

Введение в базы данных 2

2 лекция 4

Двухуровневое представление информации в интегрированных базах данных. 4

Концептуальное моделирование предметной области 4

Виды связей между сущностями 5

Концептуальное моделирование ПО в нотации языка UML. 5





Ратманова Ирина Дмитриевна Б230

Булатова Елена Сергеевна – лабораторные занятия

1 лекция


Список литературы:

  1. Базы данных курс лекций Ратманова 2006 год

  2. Проектирование баз данных разработка приложений в СУБД Interface

  3. Проектирование баз данных разработка приложений в СУБД Microsoft SQL

  4. Методология организаций поддержки 1 глава (дополнительная информация к 3 разделу)

  5. Левенец И.А – Технологии разработки ПО.

Курс состоит из 3-ёх разделов.

  1. Модели данных

  2. Системы управления базами данных

  3. Автоматизированные информационные системы

Введение в базы данных



Под информацией – понимаются любые сведения о каком либо событии сущности процессе. Являющиеся объектом некоторых операций: восприятие передача преобразование, хранение или использование.

Данные – можно определить, как информацию фиксированную в определённой форме пригожей для последующей обработки, хранения и передачи.

Под базой данных – понимается поименованная структурная совокупность взаимосвязанных данных, относящихся к определённой предметной области и находящейся под централизованным программным управлением.

Системы управления базами данных (в архитектуре клиент-сервер) – это сервер баз данных. Совокупность языковых и программных средств, предназначенные для централизованного управления базами данных и организационного доступа к ним многих пользователей.

Историческая справка. Этапы развития баз данных

  1. 1-ая половина. (60 70гг.)

ЭВМ IBM 360, EC ЭВМ

ОС: ОС ЕЭС

СУБД: Иерархические, сетевые

В это время появляется документные информационно поисковые системы.
Широкое распространение получают ГАСНТИ.

  1. 2-ая половина (60 70гг.)
    Широкое распространение Автоматизированные системы управления объектами сельского хозяйства.


Структура производственного комплекса

Тут схема

  1. 80-е годы

ЭВМ: ПЭВМ, локальные сети

ОС: Windows 98x

СУБД: псевдореляционные (в BASE - группа)

На основе ПЭВМ объединённых в локальные вычислительные сети начала автоматизированная оперативная разработка данных.
Стали создаваться автоматизированные рабочие места (АРМ).

  1. 90-е годы

ЭВМ: SUN, DEC, PC, корпоративные сети

ОС: UNIX, Linux, Windows XP

СУБД: реляционные

Начинают распространятся корпоративные, локальные, глобальные сети.
На их основе организуется сетевая обработка данных и на их основе создаётся КИС (корпоративная информационная система).

  1. Начало нового тысячелетия (2000 года).
    ЭВМ: PC, облачные вычисления

ОС: Linux, Windows XP и выше

СУБД: реляционные сервера БД, XML Nativ

Продолжается развитие сетевой обработки данных создаются корпоративные порталы, внедряются стандарты СМЭВ (стандарты меж ведомственных отношений). Создаются автоматизированные системы управления государством (электронное правительство).

2 лекция



Двухуровневое представление информации в интегрированных базах данных.


Концептуальная модель ПО →

Классическая модель БД →

Физическая модель БД

Концептуальная модель ПО отражает семантику предметной области в виде совокупности информационных объектов (сущностей), их характеристик (атрибутов) и связей (ассоциативных отношений между сущностями).

Логическая модель БД – это выраженная в терминах модели данных СУБД концептуальная модель предметной области. Осуществляется отображение концептуальной модели ПО в отображение

Физическая модель БД – это выраженная в терминах языка описания данных конкретной СУБД логическая модель БД.

Концептуальное моделирование предметной области


Модель “Cущность – связь” Питера Чена. В 1976 году американский ученый П. Чен предложил концептуальную модель предметной области. “сущность – связь” ER-модель (Entity Relationship). В основе лежит понятие сущность.

Сущность – это реальный или абстрактный объект, информация о котором должна сохраняться и быть доступной. На практике сущностями являются основные бизнес-понятия и бизнес-события предметной области.

Примерами бизнес-понятий являются: деталь, поставщик, склад

бизнес-событиями: поставка деталей, отпуск деталей

Принципиально необходимо различать понятия “тип сущности” и “экземпляр сущности”. Тип относится к набору однородных объектов, а экземпляр сущности – к конкретному предмету. Пример: деталь и гайка.

В ER диаграммах П. Чена сущности отображаются прямоугольниками.

Атрибут – это любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Атрибуты используются для того, какая информация о сущности должна быть представлена в БД. Атрибуты отображаются кружками.

Связь – это графически изображенная ассоциация, установленная между двумя сущностями. Изображаются ромбами. Может сопровождаться степенью конца связи (сколько экземпляров сущности) обязательность связи (любой экземпляр сущности должен участвовать в данной связи). Для идентификации экземпляров сущности используется понятие ключа. Ключ – это минимальная комбинация атрибутов, уникально отличающая один экземпляр сущности от другого того же типа.

Виды связей между сущностями


Существует 4 вида связей:

1) 1 к 1

Пример: заказчик – наименование

2) 1 ко многим

Пример: заказчик – заказ

Одному экземпляру сущности заказчик соответствует 0, 1 или несколько сущностей заказ.

3) Многие к 1

Пример: товар – производитель

0, 1 или много экземпляров сущности товар соответствуют 1 экземпляру производитель

4) Многие ко многим

Пример: студент – преподаватель

0, 1 или много сущностей студент соответствует 0, 1 или много сущностей преподаватель

Для примера приведем фрагмент концептуальной модели предметной области в нотации П. Чена (проект организации)

Концептуальное моделирование ПО в нотации языка UML.


Определение, визуализация, проектирование и документирование программных систем.
Он включает 12 диаграмм, которые позволяют описать статику и динамику программы. Процесс создания программных систем в объектно-ориентированном подходе состоит из трех стадий:

1) анализ требований

2) проектирование системы

3) реализация системы

При разработке автоматизированных информационных систем целесообразно использовать три вида диаграмм UML: диаграмма вариантов использования (use case), диаграмма классов (class), диаграмма деятельности (activity). На этапе анализа требований к информационной системе разрабатывается модель вариантов использования системы. Она отражает основные варианты использования, функции системы, взаимодействующих с ней актеров и некоторую структуру этих вариантов использования.

1. Актер – это человек – роль объекта вне системы.

2. Вариант использования – последовательность выполняемых системой действий, которые приводят к видимому, значимому для актера результату

Между актером и вариантом использования существует 4 вида связей: ассоциация, расширение (extend – включение добавочного поведения в исходный вариант использования без изменения последнего), включение (include – обязательное включение добавочного поведения), обобщение (→ )

Диаграмма не моделирует связи между актерами. Не соединяет связями два варианта использования кроме extend и include (порядок выполнения вариантов использования не отображается на диаграмме). Каждый вариант использования должен быть инициирован актером. База данных – это свой код диаграммы и поток информации не отображается на данной диаграмме. Каждый актер может взаимодействовать со своим набором вариантов использования. Созданию информационной системы предшествует понимание предметной области. Диаграмма вариантов использования отражает понимание предметной области и потребности заказчика к создаваемой информационной системе.

Для примера нарисуем диаграмму вариантов использования “склад деталей”
написать администратору сайта