Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна


Скачать 198.08 Kb.
НазваниеРатманова Ирина Дмитриевна, Игнатьева Елена Сергеевна
Дата публикации25.03.2013
Размер198.08 Kb.
ТипДокументы
userdocs.ru > Информатика > Документы
Базы данных.

Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна.
Ратманова «Базы данных. Курс лекций» (2006).

Методички: «Проектирование баз данных и разработка приложений в среде MS SQL Server», «Проектирование баз данных и разработка приложений СУБД InterBase».

Дополнительно: Ратманова «Методология организаций информационная поддержка принятия решений в сфере энергетики» (2006), Левенец «Технология разработки ПО», Дейт «Введение в систему баз данных».
Курс лекций:

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

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

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


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

Введение в базы данных, основы интеграции данных.
План:

  1. основные определения.

  2. историческая справка.

  3. трехуровневое представление информации.


Основные определения:

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

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

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

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

Автоматизированный банк данных (АБД) – организационно-техническая система, представляющая собой совокупность данных, аппаратного обеспечения, ПО, а также коллектива специалистов.
^ Историческая справка:

50 – первая половина 60-х годов:

ЭВМ: IBM 360 (ЕС ЭВМ).

ОС: ЕС.

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

Появляются первые документальные информационно-поисковые системы, развивается государственная автоматизированная система научно-технической информации (ГАСНТИ).

60-70 годы:

Широкое распространение получают АСУП (автоматические система управления производством) и САПР (система автоматического проектирования). Осуществляются большие масштабы автоматизации производства.


АСУП – автоматизированная система управления производством.

ТЗ – техническое задание.

АСНИ – автоматизированная система научной информации.

САПР – система автоматизированного проектирования.

АСТПП – автоматизированная система технической подготовки производства.

ГАП АСУТП – автоматизированная система управления технологическим процессом.

АСКИО – автоматизированная система контроля и испытания объектов.

АБД – автоматизированный банк данных.

Существуют готовые автоматизированные технологии поддержания жизненного цикла изделия – программные продукты, охватывающие все перечисленные подсистемы.
80-е годы:

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

ОС: Windows 98X.

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

В рамках локальных вычислительных сетей отделов стали внедряться автоматизированные рабочие места (АРМ). Начался период локальной автоматизации рабочих мест. Все, кто работает с информацией, стали создавать локальные БД.
90-е годы:

ЭВМ: SUN, DEC, PC

ОС: UNIX, Linux, Windows XP.

СУБД: Реляционные сервера.

Начинает распространяться корпоративные глобальные вычислительные сети, на их основе создаются КИС (корпоративные информационные системы), автоматизируется управление корпоративным документооборотом, на фоне концентрации производства и управления становится необходимым автоматизация корпоративного управления. В настоящее время возрастает роль информационной поддержки принятия решений: накопление информации о какой-либо деятельности, её комплексная аналитическая обработка в целях поддержки принятия решений ЛПР (лиц, принимающих решения).
Настоящее время:

ЭВМ: РС, облачные вычисления.

ОС: Linux, WinXP и выше.

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

Продолжает развиваться сетевая обработка данных с применением Интернет-технологий, создаются корпоративные порталы, внедряются стандарты межведомственных электронных взаимодействий, электронное правительство.
^ Модели данных.

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



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

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

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

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

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

План:

  1. модель «сущность-связь» Питера Чена

  2. диаграмма классов уровня анализа UML.

^ Модель «Сущность-связь».

Её называют ERD-моделью. Эта модель базируется на 3 понятиях: сущность, атрибут, связь. Сущность – реальный или абстрактный объект, информация о котором должна сохраняться и быть доступной. Это бизнес-понятие и бизнес-событие предметной области. Необходимо различать тип и экземпляр сущности. Тип сущности относится к набору однородных объектов, а экземпляр – к конкретному. Например, тип – студент, экземпляр – Иванов. Моделирование БД ведется на уровне типов. Сущности обозначаются прямоугольниками. Атрибут – любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Атрибуты используются для определения того, какая информация о сущности должна быть собрана в системе. Один или несколько атрибутов обязательно однозначно идентифицируют экземпляр сущности. Это ключ. Все экземпляры сущности должны различаться. Атрибуты обозначаются кружочками. Связь – графически изображенная ассоциация, установленная между двумя сущностями. Изображается ромбом. Существует 4 типа связи:

  • Один к одному (1:1). Одному экземпляру первой сущности соответствует один или ноль экземпляров другой сущности.

  • Один ко многим (1:М). Одному экземпляру первой сущности соответствует ноль, один или несколько экземпляров второй сущности.

  • Многие к одному (М:1). Ноль, один или несколько экземпляров первой сущности соответствует одному экземпляру второй сущности.

  • Многие ко многим (М:N). Ноль, один или несколько экземпляров одной сущности связаны с нулем, одним или несколькими экземплярами второй сущности.

Приведем пример ER-модели в нотации Питера Чена.


Обычно при разработке концептуальной модели изучается отчетность конкретной организации, структура, существующие информационные системы, законодательная база. В результате выявляются основные бизнес-понятия и бизнес-события предметной области.

Модель Питера Чена слабо формализована. В настоящее время применяются более развитые нотации, которые положены в основу CASE-средств автоматизированного проектирования ПО. CASE-средства – графический редактор, поддерживающий одну или несколько нотаций информационного моделирования, поддерживает целостность и на выходе получает программный код, соответствующий модели на выбранном ЯПВУ.

^ Диаграммы классов уровня анализа языка UML.

В январе 1997 года три теоретика объектно-ориентированного моделирования Г. Буч, Джим Рамбо, Айвар Якобсон объединились в компании Rational Software и разработали нотации языка объектно-ориентированного моделирования UML.

Процесс разработки ПО включает 4 стадии:

  1. анализ требований к автоматизированной системе.

  2. объектно-ориентированный анализ предметной области.

  3. ОО проектирование системы.

  4. реализация.

Подо все эти стадии существуют соответствующие диаграммы, а сам язык UML предназначен для визуального моделирования, проектирования и документирования программных систем. Разработка концептуальной модели предметной области выполняется в рамках 2 этапов: анализ требований и ОО анализ предметной области. Анализ требований визуализируется посредством 2 диаграмм: Use Case Diagram (диаграмма вариантов использования (ВИ) системы), Activity Diagram (диаграмма деятельности). Первая диаграмма отражает варианты использования системы и взаимодействующие с ними актеры, то есть отражает предназначение системы, а вторая отображает логику каждого ВИ. Процесс разработки АИС начинается с анализа требований, результатом которого является Use Case диаграмма. Она состоит из актеров – это роль объекта вне системы, напрямую взаимодействующей с ней (менеджер, работник склада), ВИ – это последовательность выполняемых системой действий, которая приводит к видимому, значимому для актера результату. Актер и ВИ связываются посредством связей: ассоциация (прямая линия), расширение – включение добавочного поведения в ВИ (штрихпунктирная линия), включение – включение добавочного обязательного поведения в ВИ, обобщение – отношение между общим и специфичным. Правила: не моделировать связи между актерами; не соединять связью два ВИ, кроме случаев связи включения и расширения; порядок выполнения ВИ не отражается в диаграмме; каждый ВИ должен быть инициирован актером; БД – это слой под диаграммой и потоки информации не отражаются на диаграмме; каждый актер может взаимодействовать с определенным набором ВИ.

Рассмотрим для примера фрагмент диаграммы ВИ тестовой информационной системы «склад деталей».



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

Отдельно разрабатывается концептуальная модель предметной области, и этот процесс начинается с выявления основных концептуальных объектов, которые встречаются в системе (основные бизнес-понятия и бизнес-события в системе). Необходимо стремиться, чтобы эти объекты лежали в основе системы и удовлетворяли посредством своего атрибутивного набора описанным ВИ создаваемой системы. Концептуальная модель – это декомпозиция предметной области. Требования к системе сменяются быстрее, чем реальный мир, и задача проектировщика АИС – удовлетворить потребности заказчика на основе концептов предметной области. Основной составляющей ОО анализа в UML является разработка диаграммы классов, которая определяет типы объектов системы и различного рода связи между ними.

В UML существует 3 различные диаграммы классов:

  1. концептуальная модель предметной области (модель анализа)

  2. модель спецификации классов (модель проектирования)

  3. модель реализации.

Концептуальная модель – это модель анализа.

Класс – это совокупность объектов с общими атрибутами, операциями, отношениями и семантиками. Изображается в виде прямоугольника, разделенного на 3 части: имя класса, атрибуты, методы.

Отношение определяет ассоциации между классами: зависимость – это семантическое отношение между двум сущностями, при котором изменение одной влечет изменение другой (штрихпунктирная линия со стрелкой), ассоциация – структурное отношение, описывающее совокупность связей (прямая, на которой показывается степень связи (сколько экземпляров связано), обязательность (для всех экземпляров она должна быть), имя связи)). Варианты степеней: n – много, 0..0, 0..1, 0..n, 1..1, 1..n. Разновидностью ассоциации является агрегирование – отношение «часть-целое». Около целого рисуется ромб, а у частей прямые. Если ромб закрашен, то поддерживается каскадное удаление (удаление целого влечет удаление всех частей). Обобщение – отношение «подтип-супертип» (стрелка). Реализация – связь между интерфейсами и реализующими классами (штрихпунктирная линия со стрелкой).

Рассмотрим концептуальную модель «склад деталей».


Склад

Строка отпуска

Количество


Примечание:

  1. деталь сделана из конкретного материала. Эта идея использования справочника материалов. Связь М:1

  2. может не быть деталей, сделанных из какого-то материала (0..n)

  3. деталь лежит на конкретном складе, много деталей связаны с конкретным складом, склад может быть пуст. Склад – справочник для детали. Справочник всегда связан отношением «многие к одному»

  4. во время поставки поставляется одна деталь конкретным поставщиком, но во время поставки обязательно должны быть и поставщик и деталь

  5. поставщик находится в одном конкретном городе. Город – это справочник для поставщиков, могут быть города, где нет поставщиков.

  6. накапливается историчность регистрационных сведений поставщика, у него может меняться адрес, название и др. Атрибуты юридического лица: название, юридический адрес, ИНН, ОГРН, организационно-правовая форма, ФИО руководителя, телефон

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

  8. клиент может быть юридическим лицом или частным предпринимателем (ИП). Рационально поддерживать 2 отдельных справочника со своим реквизитом. Клиент – супер-тип двух подтипов: юридическое лицо и ИП. Во время отпуска связь поддерживается с 1 клиентом, при этом поставляется несколько видом деталей.

Принцип создания концептуальной модели:

  • Составить список понятий на основе анализа требований и отобразить выбранные классы на концептуальной модели.

  • Добавить необходимые ассоциации между классами, учтя при этом экземплярность связей.

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

  • Можно выделить следующие категории классов:

    • Типы актеров (люди, организации).

    • Актеры (роли, участники).

    • Физические объекты (реальные вещи).

    • Дескриптивные вещи (спецификации описания).

    • Транзакции (события, процессы).

    • Элементы транзакций (строка заказов, поставки).

    • Места, контейнеры (магазин, склад).

В настоящее время есть готовые шаблоны концептуальных моделей предметных областей.

Таким образом, склад деталей базируется на 3 понятиях: деталь, поставщик и клиент. Введен ряд справочников в целях нормализации некоторых атрибутов: материал, город, склад. В нашей модели 2 основных бизнес-события: поставка и отпуск деталей. Это связь «многие ко многим» между деталью и поставщиком или деталью и клиентом. Кроме того, принято решение, что отпуск может включать несколько деталей, то есть расширяться. Для этого вводится строка отпуска. Клиент является супертипом для подтипов юридическое лицо и ИП, которые реализуются отдельными справочниками.

Принципы логического моделирования базы данных.

План:

  1. определение типов и моделей данных

  2. иерархическая и сетевая модели

  3. реляционная модель.

В языке высокого уровня поддерживаются достаточно развитые типы данных, включая простые, структурированные, ссылочные и абстрактные (объекты). Простые типы являются базовыми по отношению к ЭВМ и различаются как целый, вещественный, логический, литерный и т.д. Тип данных – это совокупность структуры данных, операций, накладываемых на данные, и ограничений целостности, то есть мероприятий, которые обеспечивают корректную работу операций с данным типом. Структурный тип предназначен для конструирования из конечного набора базовых типов сложных структур данных. Выделим три основные структурных типа: запись (структура), массив, файл, рекурсивная структура. Массив – совокупность данных одного типа. Операции работы с массивом: создание, задание изначальных значений элементов массива, выбор элементов по значению индексов (порядковому номеру) и избирательное обновление элементов. Ограничения целостностями – это то, что все элементы одного типа и индекс – целое число. Структура (тип записи) – совокупность элементов разного типа. Например, структура – сотрудник включает элементы табельный номер, ФИО, дата рождения. Структура не используется в чистом виде, а для конструирования более сложных типов, в частности файлов. Файл – это совокупность записей одинаковой структуры (массив структур). Файл хранится на жестком диске и предназначен для хранения данных. Функции с файлом: создать, установить указатель на начало файла, записать в конец файла новую запись, считать информацию по указателю и получить указатель на конец файла. Рекурсивный тип – образуется суперпозиция типов данных в целях получения более сложных структур, например, деревьев, поддерживается с помощью указателей.

^ Ссылочный тип – указатель – это адрес памяти. Всё дисковое пространство разделено на страницы (2, 4, 8 и т.д. килобайт), и адрес памяти – это номер страницы + относительный номер байта внутри страницы. Абстрактный тип (объект) – это интерпретируемый структурированный тип с функциями, определенными над его элементами. При этом определяются имена, типы элементов, функции (методы), а также правила (ограничения целостности) применения этих функций к описанным элементам. Для поддержания во внешней дисковой памяти более сложных структур данных на уровне СУБД поддерживаются модели данных, включая иерархическую, сетевую и реляционную. Модель данных – это совокупность структур данных и правил их порождения, операций над ними и ограничений целостности как перечень мероприятий, направленных на поддержание БД в актуальном состоянии. Целостность – это точность, корректность данных в базе в любой момент времени. Ограничение целостности – набор мероприятий, направленных на поддержание целостности базы и корректности выборки информации.

^ Иерархическая и сетевая модель данных.

На первых этапах внедрения БД (50–80 годы) широко использовались СУБД первого поколения на ЕС ЭВМ – иерархические и сетевые СУБД.

Иерархическая модель организует структуру в виде упорядоченного дерева, вершины (узлы) соответствуют сущностям и называются типами записей. Тип записи может состоять из нескольких элементов, а дуга, связывающая типы, называется «исходный-порожденный» и соответствует типу «один ко многим» (одному экземпляру исходной записи соответтствует ноль, один или несколько порожденных записей). Доступ к каждому узлу осуществляется по иерархическому пути – это последовательность типов записей от корня дерева. Верхняя вершина – корень, последняя – лист, много деревьев – лес. Расширением типа записи является таблица, а расширением связи – множество соединений между строками таблиц. Каждая строка таблицы – это экземпляр типа записи. Ограничением целостности является то, что в вершину всегда входит только одна дуга. Операции: включение данных (экземпляр порожденной записи не может существовать в отсутствии экземпляра исходной), которое осуществляется по иерархическому пути (указываются ключи записи); удаление данных (при удалении экземпляра исходной записи автоматически удаляются все экземпляры порожденных, так как экземпляры записей реализуются посредством указателей); извлечение данных осуществляется по иерархическому пути посредством указания ключей записей; обновление данных – изменение значений производится только над извлеченными записями. В экземпляре записи всегда есть ячейка с указателем на брата и на сына. Таким образом, связи в иерархической модели основаны на указателях. Для того, чтобы реализовать концептуальную модель предметной области нужно ввести 6 иерархических структуры: материал – деталь – поставка, склад – деталь – поставка, город – поставщик – поставка, материал – деталь – отпуск, склад – деталь – отпуск, клиент – отпуск.

Достоинством иерархической модели является простота и интуитивное восприятие информации. В настоящее время поисковые системы (над реляционными базами) основаны на построении навигационного иерархического интерфейса. Недостатком этой модели является искусственный с избыточностью подход реализации связей «многие ко многим» и процедурность операций манипулирования данными.

Представим для примера реализацию на иерархической модели базы данных «склад деталей».

Город

Клиент

Материал

Материал

Поставщик

Отпуск

Деталь

Деталь

Поставка

Строка отпуска

Поставка

Отпуск

Деталь

Деталь

Поставщик

Клиент

Для реализации базы «склад деталей» на иерархической СУБД необходимо формирование как минимум четырех иерархических структур (лес). Так как отношение «поставщик–деталь», «клиент–деталь» являются «многие ко многим», поэтому необходима избыточность на уровне модели БД. Связь «многим ко многим» развязываются 2 иерархиями.

^ Сетевая модель.

Это ориентированный граф, в узлах которого расположены типы записей, граф произвольного вида и в вершину может входить несколько дуг. Идея сетевой модели предложена ассоциацией КОДАСИЛ. Характеристика модели КОДАСИЛ:

  1. элемент данных – базовая поименованная единица

  2. агрегат – совокупность данных: массив, структура

  3. запись – поименованная совокупность элементов и/или агрегатов данных

  4. набор – поименованная совокупность записей, образующих двухуровневую иерархическую структуру «исодный–порожденный». Каждый тип набора представляет собой отношение между двумя типами записей. Каждый экземпляр набора содержит один экземпляр записи «владелец» и ноль, один или несколько экземпляров «член набора».

Сеть – это совокупность иерархий.

Ограничением целостности является следующее: в конкретном экземпляре набора экземпляр «член набора» не может иметь более одного экземпляра записи «владелец». Таким образом сеть набирается совокупностью иерархий «один ко многим». Операции: извлечь – извлечь запись можно по ключу, от извлеченной записи возможен переход к подчиненным; включить – можно в ранее объявленный набор, а можно в т.н. сингулярный набор, у которого пока нет владельца; переключить – из одного набора в другой; удалить – удаляется не запись, а связи; модифицировать – изменить значение аргументов в выбранной записи. Достоинства – простота реализации связи «многие ко многим».

Сетевые СУБД – IDMS –> СЕТЬ и СЕТОР.

Сетевые модели хороши для реализации технических коммуникаций (описание электрических сетей, тепловых сетей) и применяются в инженерных расчетах. В настоящее время реализуются либо как собственные разработки, либо на ОО СУБД.

Пример сетевой модели базы «склад деталей».

Таким образом в БД хранятся экземпляры типов записей «город», «поставщик», «поставка», «деталь» и т.д., которые связаны в рамках определенных экземпляров наборов отношениями «один ко многим». Например, деталь 1 в типе набора «деталь – поставка» является владельцем экземпляров поставка 2 и поставка 6, а деталь 2 в этом типе набора является владельцем поставки 1, 2, 7. Деталь 1 и 2 находятся в разных связках, то есть в разных экземпляров набора.

К ранним видом СУБД относятся псевдореляционные. Они получили распространение на ПЭВМ, это системы dBase группы. К ним относятся Clipper, FoxPro, FoxBase. В этих системах каждая таблица (тип записи) хранится в отдельном файле с расширением dbf, например, отдельно файл «Город», файл «Поставщик» и т.д. Между файлами связи поддерживались на программном уровне в клиентском приложении. Для каждого файла создавались индексы для обеспечения быстрого доступа к записям файлов по ключу. Далее мы перейдем к реляционной модели, которая поддерживает ссылочную целостность между сущностями.

^ Реляционная модель данных.

Характеристика модели.

Предложил концепцию реляционной модели Эдвард Кодд, он предложил вложить в основу алгебру отношений. В основе реляционной модели лежит понятие теоретико-множественных отношений – это подмножество декартова произведения доменов, а домен – это множество значений, которые принимает атрибут (множество названий городов, фамилий сотрудников). Отношение (таблица) – подмножество декартова произведения одного или более доменов.

Имя отношения

А1

А2

А3

А4

– атрибуты

А11

А12

А13

А14

– кортежи выборки

А21

А22

А23

А24




А31

А32

А33

А34















А11, А12 – это значения атрибутов.

Реляционная база данных – это множество связанных между собой отношений (таблиц), и при этом связи между таблицами задаются посредством внешних или вторичных ключей, то есть атрибутов таблиц, которые в каких-то других отношениях являются первичными. Список имен атрибутов называется схемой отношения. Каждое отношение имеет уникальное имя. Свойства отношений: нет одинаковых кортежей – все записи отличаются по первичному ключу; кортежи не упорядочены сверху вниз; атрибуты не упорядочены слева направо (в операциях реляционной алгебры строки и столбцы отношений могут просматриваться в любом порядке и последовательности безотносительно к их информационному содержанию смыслу); все значения – скалярные и все элементы столбца имеют одинаковую природу, так как построены на одном домене. Отношение с такими свойствами называется нормализованным. В отношении один или несколько атрибутов являются ключом, то есть однозначно характеризует кортеж. Свойства ключа: уникальная идентификация выборки, неизбыточность (удаление любого атрибута лишает его свойства уникальности). Наряду со смысловым ключом используется инкрементный (счетчик), состоящий из одного числового поля, который автоматически наращивается.

^ Правила отображения концептуальной модели предметной области в реляционную БД.

На рисунке 5 изображена концептуальная модель. Отобразим её в реляционную.

  1. отображение сущностей в реляционные отношения, которые нормализованы

  2. отображение ассоциаций связано с использованием ссылочной целостности между таблицами. Ассоциативное отношение 1:1, 1:М, М:1 реализуются посредством помещения внешнего вторичного ключа в сущность, из которой исходит стрелка ассоциации. Этот ключ соответствует первичному ключу, на который указывает стрелка. Связи «многие ко многим» требует ведения перекрестной таблицы, в которую включается в качестве вторичных ключей первичные ключи связываемых сущностей.



  1. отображение агрегации осуществляется с помощью ассоциаций, при этом заводится отдельная таблица «часть» с вторичным ключом, связывающим её с таблицей владельцев (целое)

  2. отображение обобщения чаще всего осуществляется посредством отображения каждого подтипа в отдельную таблицу с включением в неё вторичного ключа, соответствующего первичному ключу таблицы супертипа. Пример: «клиент» (код клиента) для подтипов «организация» (ОГРН, код клиента), «ИП» (ИНН, код клиента).

Целостность реляционной модели.

Целостность объектов (отношений) – в базе не допускается, чтобы какой-либо атрибут из первичного ключа принимал неопределенные значения.

Ссылочная целостность – БД не должна содержать несогласованных значений внешних ключей (FK). Если отношение R2 имеет среди своих атрибутов какой-то внешний ключ, который соответствует первичному ключу (PK) отношения R1, то каждое значение FK должно быть равно значению РК. Пример: все коды материалов таблицы «деталь» должны присутствовать как первичные ключи в таблице материалов.

^ Методология моделирования IDEF1X.

Для описания логической модели реляционной базы данных существует специальная нотация, которая называется IDEF1X. Это одна из нотаций семейства IDEF – семейство моделей, используемых для описания информационных моделей систем. В это семейство входит IDEF0 – для описания бизнес процессов, IDEF3 – для описания систем документооборота, IDEF5 – для описания БЗ.

  1. сущности изображаются в виде прямоугольников с прямыми и закругленными углами. Прямоугольники с закругленными углами представляют зависимые сущности, уникальные идентификаторы которых включают внешний ключ, определяющий связь с другой сущностью. Независимые сущности (обычные прямоугольники) в первичном ключе не содержат вторичный. Содержание первичного ключа в прямоугольнике отчеркивается. Над прямоугольником пишется имя сущности. В нижней части прямоугольника указываются все остальные атрибуты. Связи изображаются в виде линий: сплошных и пунктирных. Точка означает конец «много». Возможно уточнение количества экземпляров. Нотация IDEF1X положена в основу Case-средства ER Win. Дадим основные элементы нотации:

Нотация

Название

Значение

Отпуск

^ Код отпуска

Код клиента (FK)

Независимая сущность

Сущность, в уникальный идентификатор которой не входит связь с другой сущностью.

Строка отпуска

Код отпуска (FK)

^ Номер строки

Количество

Код детали (FK)

Зависимая сущность

Сущность, в уникальный идентификатор которой входит связь с другой сущностью.

Прямая с кругом на конце

Идентифицирующая связь

Связь между сущностями, являющаяся частью уникального идентификатора.

Пунктирная с точкой на конце

Неидентифицирующая связь

Связь между сущностями, не являющаяся частью уникального идентификатора.

Прямая с точкой и буквой Р

1…n




Прямая с точкой и буквой Z

0…1




Отрезок с жирными точками на концах

M:N




Две прямые с кругом над ними

Полное наследование

Сущность родитель является супертипом для потомков, которые все должны быть указаны

Прямая с кругом над ней

Неполное наследование

Не все потомки могут быть указаны

Ромб и прямая с точкой

Агрегация (если ромб заштрихован, то каскадное удаление)




Похожие:

Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна iconРатманова Ирина Дмитриевна, Игнатьева Елена Сергеевна
Методички: «Проектирование баз данных и разработка приложений в среде ms sql server», «Проектирование баз данных и разработка приложений...
Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна iconАлехин алексей анатольевич алехно анастасия александровна белоусова ксения андреевна
Перфильева ирина авеноровна полтарацкая елена сергеевна почтариков константин сергеевич
Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна iconПермская синематека и госкиноцентр «пермкино» рекомендуют: художественные...
Военная драма. Реж. Станислав Ростоцкий. В ролях: Андрей Мартынов, Ирина Шевчук, Ольга Остроумова, Елена Драпеко, Ирина Долганова,...
Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна iconКасаткина Елена Сергеевна Возраст
...
Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна iconСанкт-Петербургский государственный детский ледовый театр елена бережная...
Станиславом Войтюком. Биография Станислава богата, он работал над постановкой программ таких фигуристов как: Мария Петрова – Алексей...
Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна iconШевчик Елена Сергеевна проходила производственную практику в отделе...
Шевчик Елена Сергеевна проходила производственную практику в отделе товарной номенклатуры и торговых ограничений Тюменской таможни...
Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна iconКурс Время Дата Корпус аудитория число студентов Ф. И. О. Студентов (№ группы)
ЛЛ5),Ломакина Татьяна Александровна (10ЛЛ5),Алхасави Алмоса Кутейба (10ЛЛ6),Трушникова Евгения Анатольевна (10ЛЛ6),Блинова Ольга...
Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна iconКурс Время Дата Корпус аудитория число студентов Ф. И. О. Студентов (№ группы)
ЛЛ5),Ломакина Татьяна Александровна (10ЛЛ5),Алхасави Алмоса Кутейба (10ЛЛ6),Трушникова Евгения Анатольевна (10ЛЛ6),Блинова Ольга...
Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна iconНиколай Николаевич Никулин Воспоминания о войне Хранитель
Ирина Сергеевна (1930 г рожд.), заведует отделением рисунка в отделе истории западноевропейского искусства Государственного Эрмитажа....
Ратманова Ирина Дмитриевна, Игнатьева Елена Сергеевна iconЛапшина Мария Сергеевна 2 курс 11 группа
...
Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2015
контакты
userdocs.ru
Главная страница