
- •230111 Компьютерные сети
- •Оглавление
- •Аннотация
- •Для чего нужны базы данных.
- •1.Представление данных в памяти компьютера.
- •1.1.Типы и структуры данных
- •1.1.1.Основные типы данных.
- •1.1.2.Обобщенные структуры или модели данных.
- •1.2.Методы доступа к данным.
- •1.2.1.Методы поиска по дереву.
- •1.2.2.Хеширование.
- •2.Модель "сущность-связь".
- •2.1.Представление данных с помощью модели "сущность-связь".
- •2.1.1.Назначение модели.
- •2.1.2.Элементы модели.
- •2.2.Диаграмма "сущность-связь".
- •Выделим интересующие нас сущности и связи:
- •Обобщая все проведенные выше рассуждения, получим диаграму "сущность-связь", показанную на слудющем рисунке.
- •2.3.Целостность данных.
- •2.4.Обзор нотаций, используемых при построении диаграмм "сущность-связь"
- •2.4.1.Нотация Чена.
- •2.4.2.Нотация Мартина
- •2.4.3.Нотация idef1x.
- •2.4.4.Нотация Баркера.
- •3.Дореляционные модели представления данных.
- •3.1.Иерархическая модель данных.
- •3.1.1.Структура данных.
- •3.1.2.Операции над данными, определенные в иерархической модели:
- •3.1.3.Ограничения целостности.
- •3.2.Сетевая модель данных.
- •3.2.1.Структура данных.
- •3.2.2.Операции над данными.
- •4.1.2.Свойства отношений.
- •4.2.Теория нормальных форм.
- •4.2.1.Функциональные зависимости.
- •4.2.5. Bcnf - нормальная форма Бойса-Кодда.
- •4.2.6. Многозначные зависимости и четвертая нормальная форма (4nf).
- •4.2.7. Зависимости по соединению и пятая нормальная форма (5nf).
- •4.3.Ограничения целостности
- •4.3.1.Целостность сущностей.
- •4.3.2.Целостность ссылок
- •Проекция
- •Объединение
- •Пересечение
- •Разность
- •Произведение
- •Деление
- •Соединение
- •4.5.Реляционное исчисление.
- •4.6.Язык sql
- •4.6.1.Типы данных sql.
- •5.Проектирование реляционных баз данных.
- •5.1.Этапы проектирования данных
- •5.2.Инструментальные средства проектирования информационных систем.
- •5.3.Методологии функционального моделирования.
- •5.3.1.Диаграммы потоков данных. Нотация Йордона - Де Марко
- •5.3.2.Другие нотации, используемые при построении диаграмм потоков данных.
- •5.3.3.Методология sadt (idef0).
- •5.3.4.Сравнительный анализ методологий функционального моделирования.
- •5.4.Концептуальное моделирование. Пример построения модели "сущность-связь"
- •5.5.Правила порождения реляционных отношений из модели "сущность-связь"
- •5.5.1.Бинарные связи
- •5.5.3.Иерархические связи.
- •5.6.Проектирование реляционной базы данных на основе декомпозиции универсального отношения.
- •5.7.Обзор некоторых case-систем.
- •5.7.1.Power Designer компании Sybase.
- •6.Современные направления развития баз данных.
- •6.1.Ограничения реляционных баз данных.
- •6.2.Постреляционные субд.
- •6.3.Объектно-ориентированные субд.
- •6.3.1.Объектно-ориентированная парадигма.
- •6.3.2.Объектно-ориентированные субд.
- •6.3.3.Стандарт odmg.
- •6.3.4.Объектные расширения реляционных субд. Язык sql-3.
- •6.4.Объектно-реляционные субд.
- •6.5.Нечисловая обработка и ассоциативные процессоры.
- •7.Физическая организация субд.
- •7.1.Архитектура "клиент-сервер".
- •7.1.1.Основные понятия.
- •7.1.2.Модели взаимодействия клиент-сервер.
- •7.1.3.Мониторы транзакций.
- •7.2.Обработка распределенных данных.
- •7.3.Структура сервера базы данных.
- •8.Базы знаний.
- •8.1.Понятие системы баз знаний.
- •8.2.Структура и функции системы баз знаний.
- •8.3.Инструментальные средства построения систем баз знаний.
- •9.Источники информации по базам данных в Internet.
- •9.1.Электронные журналы и другие периодические издания.
- •9.2.Исследовательские группы и проекты.
- •9.3.Компании - разработчики.
5.3.2.Другие нотации, используемые при построении диаграмм потоков данных.
Помимо нотации Йордона - Де Марко для элементов DFD-диаграм могут использоваться и другие условные обозначения (OMT, SSADM, нотация Гейна - Сарсона и т.д.). Все они обладают практически одинаковой функциональностью и различаются лишь в деталях. Например, в нотации Гейна-Сарсона для обозначения функций используются прямоугольники с закругленными углами, а также не рассматриваются управляющие потоки данных. В остальном эти системы обозначений эквивалентны.
Инструментальные средства проектирования (CASE - системы), как правило, поддерживают несколько нотаций представления DFD-диаграмм.
Одной из таких систем является PowerDesigner компании Sybase, который поддерживает следующие технологии моделирования:
Моделирование данных: концептуальная, логическая и физическая модели данных, и расширение для проектирования хранилищ данных, основанное на IE (Information Engineering) методологии или нотации IDEF 1/x.
Моделирование приложений: все диаграммы UML и управление реализацией персистентных объектов за счет расширенной возможности описания OR-отображений (Object/Relational mapping). Техники моделирования с использованием XML и связь таких моделей с UML и моделями данных.
Моделирование бизнес процессов: диаграммы описания бизнес процессов, интуитивно понятные нетехническим пользователям, моделирование языка исполнения бизнес процессов с поддержкой нотаций BPEL4WS и ebXML.
Моделирование Архитектуры предприятия: моделирование архитектуры предприятия, - от бизнес целей до реализации, с использованием уникальной технологии соединения и синхронизации (Link and Synch). Это позволяет избавиться от лишней информации и обеспечивает прозрачность описания, что увеличивает конкурентоспособность бизнеса, повысив скорость реагирования на изменения в экономике, технологиях и законодательстве.
5.3.3.Методология sadt (idef0).
Методология SADT (Structured Analisys and Design Technique) разработана Дугласом Т. Россом в 1969-73 годах. Она изначально создавалась для проектирования систем более общего назначения по сравнению с другими структурными методами, выросшими из проектирования программного обеспечения. IDEF0 (подмножество SADT) используется для моделирования бизнес-процессов в организационных системах и имеет развитые процедуры поддержки коллективной работы.
В терминах IDEF0 система представляется в виде комбинации блоков и дуг. Блоки представляют функции системы, дуги представляют множество объектов (физические объекты, информация или действия, которые образуют связи между функциональными блоками). Место соединения дуги с блоком определяет тип интерфейса:
Правила интерпретации модели:
Функциональный блок (функция) преобразует входные объекты в выходные.
Управление определяет, когда и как это преобразование может или должно произойти.
Исполнитель осуществляет это преобразование.
С дугами связываются метки на естественном языке, описывающие данные, которые они представляют. Дуги показывают, как функции системы связаны между собой, как они обмениваются данными и осуществляют управление друг другом. Выходы одной функции могут быть входами, управлением или исполнителями другой.
Дуги могут разветвляться и соединяться. Ветвление означает множественность (идентичные копии одного объекта) или расщепление (различные части одного объекта). Соединение означает объединение или слияние объектов.
Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня. Эти блоки представляют подфункции (подмодули) исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничивается, зато рекомендуется на одной диаграмме использовать не менее 3 и не более 6 блоков.
На следующем рисунке, видим IDEF0-модель деятельности описанного выше предприятия.