Как сделать физическую модель бд

Добавил пользователь Валентин П.
Обновлено: 10.09.2024

Физическая модельданных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных задач.

Различают два уровня физической модели:

Физическая модель содержит всю информацию, необходимую для реализации конкретной БД.

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

Модель СУБД автоматически генерируется из трансформационной модели и является точным отображением системного каталога СУБД. ERwin непосредственно поддерживает эту модель путем генерации системного каталога.

Физический уровень представления модели зависит от выбранного сервера. ERwin поддерживает практически все распространенные СУБД, всего более 20 реляционных и нереляционных БД.

При смене СУБД ERwin предлагает автоматически преобразовать тип данных, связанный с каждым атрибутом, на ближайший, доступный для новой СУБД.

ERwin автоматически создает имена таблиц и колонок на основе имен соответствующих сущностей и атрибутов, учитывая максимальную длину имени и другие синтаксические ограничения, накладываемые СУБД. При генерации имени таблицы или колонки по умолчанию все пробелы автоматически преобразуются в символы подчеркивания, а длина имени обрезается до максимальной длины, допустимой для выбранной СУБД. Информация на логическом и физическом уровнях в ERwin хранится отдельно.

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

Представления (view), или, как их иногда называют, временные или производные таблицы, представляют собой объекты БД, данные в которых не хранятся постоянно, как в таблице, а формируются динамически при обращении к представлению. Представление не может существовать само по себе, а определяется только в терминах одной или нескольких таблиц. Применение представлений позволяет разработчику БД обеспечить каждому пользователю или группе пользователей свой взгляд на данные, что решает проблемы простоты использования и безопасности данных. ERwin имеет специальные инструменты для создания и редактирования представлений.

Для редактирования представления служит диалог представлений.

ERwin позволяет проводить процессы прямого и обратного проектирования БД. Это означает, что по модели данных можно сгенерировать схему БД или автоматически создать модель данных на основе информации системного каталога.

Процесс генерации физической схемы БД из логической модели данных называется прямым проектированием При генерации физической схемы Erwin включает триггеры ссылочной целостности, хранимые процедуры, индексы и другие возможности, доступные при определении таблиц в выбранной СУБД. Процесс генерации логической модели из физической базы данных называется обратным. Erwin позволяет создать модели данных путем обратного проектирования имеющейся БД. После того, как модель создана, можно переключиться на другой сервер (модель будет конвертирована) и произвести прямое проектирование структуры БД для другой СУБД.

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

· создание логической модели данных,

· переход к физической модели данных,

· генерация системного каталога БД.

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

Под удаленными базами данных понимаются, как правило, базы данных архитектуры "клиент-сервер". В этом случае обращение к БД происходит через сервер БД и основным инструментом работы с БД являются запросы на языке SQL.

Процесс создания удаленных БД состоит из:

· создания логической модели данных,

· перехода к физической модели данных,

· генерации системного каталога БД.

Генерация системного каталога также осуществляется командами языка SQL.

В отличие от локальных баз данных, создание системного каталога удаленных БД часто проводится в несколько этапов. Сначала генерируются SQL-команды создания таблиц, связей, триггеров и хранимых процедур, затем полученные SQL скрипты анализируются, редактируются и дополняются, после чего устанавливается связь с сервером БД и под управление сервера создается БД

Для генерации триггеров ERwin использует механизм шаблонов - специальных скриптов, использующих макрокоманды. При генерации кода триггера вместо макрокоманд подставляются имена таблиц, колонок, переменные и другие фрагменты кода, соответствующие синтаксису выбранной СУБД. Шаблоны триггеров ссылочной целостности, генерируемые ERwin по умолчанию, можно изменять, кроме того, можно переопределить как триггеры для конкретной связи, так и шаблоны во всей модели в целом.

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

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

Подготовка к генерации базы данных физического уровня начинается с создания пустой БД в среде той СУБД, куда планируется генерировать ER-диаграмму. Для этого надо запустить СУБД Access, выполнить команду на создание новой БД, присвоить ей имя и сохранить (рис. 4.38).

Затем открываем ER-диаграмму в среде ERwin и с помощью списка выбора в стандартной панели инструментов производим переключение между логической и физической моделью (рис. 4.39). При переключении, если физической модели еще не существует, она будет создана автоматически.

Теперь необходимо выбрать СУБД, в которой будем производить генерацию БД физического уровня. Для этого следует выполнить команду DATABASE/Choose database, в появившемся диалоговом окне (рис. 4.40) выбрать интересующую СУБД Access и щелкнуть по кнопке .

Рис. 4.38. Пустая БД с именем test_db в СУБД Access

Рис. 4.39. Физическая модель БД в ERwin

Рис. 4.40. Диалог выбора СУБД (сервера)

Для установления соединения БД из ERwin с целевой СУБД Access необходимо выполнить команду DATABASE/Database connection. В появившемся диалоговом окне (рис. 4.41) необходимо указать путь к БД в СУБД Access, вписать имя admin и нажать кнопку Connect.

Рис. 4.41. Диалог присоединения к СУБД Access

Для генерации БД физического уровня в среде СУБД Access необходимо выполнить команду TOOLS/Forward Engineering/Schema Generation. В итоге получают диалог генерации схемы БД (рис. 4.42), который имеет три закладки.

Options. Служит для задания опций генерации объектов базы данных — триггеров, таблиц, представлений, колонок, индексов и т. д. Для задания опций генерации какого-либо объекта следует выбрать объект в левом списке закладки, после чего включить соответствующую опцию в правом списке.

Рис. 4.42. Диалог генерации схемы БД

Во вкладке Summary отображаются все опции, заданные во вкладке Options. Список опций в Summary можно редактировать также, как и в Options.

Comment. Позволяет внести комментарий для каждого набора опций.

Каждый набор опций может быть именован (окно Option Set, кнопки New, Rename и Delete) и использован многократно.

Кнопка Preview вызывает диалог Schema Generation Preview, в котором отображается SQL-скрипт, создаваемый ERwin для генерации системного каталога СУБД (рис. 4.43).

Кнопка Print диалога предназначена для вывода на печать создаваемого ERwin SQL-скрипта.

Кнопка Report сохраняет тот же скрипт в ERS- или SQL-текстовом файле. Эти команды можно в дальнейшем редактировать любым текстовым редактором и выполнять при помощи соответствующей утилиты сервера.

Нажатие на кнопку Generate приведет к запуску процесса генерации схемы. Возникает диалог связи с базой данных, устанавливается

Рис. 4.43. Программа генерации таблиц БД (SQL-скрипты)

сеанс связи с сервером базы данных (СУБД Access), и начинает выполняться SQL-скрипт. При этом возникает диалог Generate Database Schema (рис. 4.44).

По умолчанию в диалоге Generate Database Schema включена опция Stop If Failure. Это означает, что при первой же ошибке выполнение SQL-скрипта прекращается. Щелкнув по кнопке Continue, можно продолжить выполнение. Кнопка Abort прерывает выполнение. При выключенной опции Stop If Failure SQL-скрипт будет выполняться, несмотря на встречающиеся ошибки.

Рис. 4.44. Диалог Generate Database Schema

Для выполнения обратного проектирования следует выбрать пункт меню Tools/Reverse Engineer. После выполнения SQL-скрипта (см. рис. 4.43) в среде СУБД Access создается БД физического уровня (рис. 4.45).

Рис. 4.45. Структура БД физического уровня в СУБД Access

Таким образом, на основе физической модели ERwin можно сгенерировать системный каталог СУБД или соответствующий SQL- скрипт. Этот процесс называется прямым проектированием (Forward

Engineering). Тем самым достигается масштабируемость — создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую пакетом ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering).

На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот).

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

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

Типы физических моделей данных

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

• БД на плоских файлах, или неструктурированные БД. В такой базе данных все данные располагаются в одном файле в виде набора строк и столбцов. В этой архитектуре отсутствует связь между различными плоскими файлами, поскольку ни одна из этих БД ничего не знает об остальных. Она поддерживает быстрое обновление и чтение данных за счет метода индексирования ISAM (indexed sequential access method — индексно- последовательны и метод доступа). Технология ISAM применяется в унаследованных мэйнфреймовых БД и небольших базах данных, располагающихся на ПК.

• Реляционные БД. Здесь данные хранятся в наборе таблиц и столбцов. Реляционные базы данных сочетают преимущества плоских файлов и иерархических баз данных, обеспечивая хорошую производительность и гибкость в хранении данных. Благодаря возможности определять связи между таблицами на основании уникальных значений, реляционные базы данных — одни из самых популярных. Однако важно понимать, что другие модели также применяются и что разработчикам систем масштаба предприятия иногда приходится работать с несколькими типами баз данных одновременно. В реляционной модели основное внимание уделяется хранению, выборке и обеспечению целостности данных. Структурированный язык запросов SQL (Structured Query Language) позволяет эффективно извлекать связанные элементы данных вне зависимости от того, в одной или нескольких таблицах они хранятся. Целостность данных обеспечивается механизмом правил (rules) и ограничений (constraints).

В Белгородском филиале МЭСИ в настоящее время для хранения дынных применяется Microsoft SQL Server 2000. Поэтому для системы было выбрано предпочтение реляционной базе данных. Физическая модель отражает целевую среду реализации.

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

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

Таблицы являются физическим представлением объекте в-сущностей в реляционной базе данных. Они способны хранить самые разные данные — имена, адреса, изображения, аудио и видео файлы, документы Microsoft Word и т.п. Благодаря своей гибкости базы данных применяются для хранения не только простых текстовых данных, но и корпоративной базы знаний предприятия, независимо от формы этих знаний. База данных представляет связи между различными элементами данных.

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

Традиционный формат взаимодействия с реляционными данными — ANSI строки, а язык — SQL. Этот язык, напоминает английский и представляет операции, выполняемые с базой данных, в виде понятных человеку выражений, таких, как Insert (вставка), Update (обновление) и Delete (удаление). Большинство баз данных удовлетворяют ANSI-стандарту SQL, хотя его версии и расширения в разных системах отличаются.

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

В ходе анализа диаграммы сущность-связь были определены следующие таблицы:

Таблица Users содержит описание пользователей.

Поле таблицы	Тип данных	Описание
UserID	INTEGER	Уникальный идентификатор пользователя
Login:	VARCHAR(20)	Логин пользователя
Password	VARCHAR(100)	Пароль пользователя
LastName	VARCHAR(100)	Фамилия
Email	VARCHAR(100)	Электронная почта
FirstName	VARCHAR(100)	Имя пользователя

Таблица Roles содержит описание ролей пользователя

Поле таблицы	Тип данных	Описание
RoleID	INTEGER	Уникальный идентификатор
RoleName	VARCHAR(100)	Название роли
Description	VARCHAR(100)	Описание роли

Сущности Пользователь и Роли состоят в отношениях один ко многим, поэтому в результате нормализации была выделена таблица UserRoles, в которой определенному пользователю соответствует определенная роль.

Поле таблицы	Тип данных	Описание
UserRoleID	INTEGER	Уникальный идентификатор
UserID	VARCHAR(100)	Идентификатор пользователя
RoleID	VARCHAR(100)	Идентификатор роли

Таблица Form содержит необходимую информацию об анкете

Поле таблицы	Тип данных	Описание
FormID	INTEGER	Уникальный идентификатор пользователя
FormName	VARCHAR(250)	Название анкеты
CreatedDate	DATETIME	Дата создания
Author	VARCHAR(100)	Идентификатор пользователя (автора)

Таблица Question содержит список вопросов

Поле таблицы	Тип данных	Описание
QuestionID	INTEGER	Уникальный номер вопроса
QuestionType	INTEGER	Тип вопроса
QuestionText	TEXTt	Текст вопроса

Поле таблицы	Тип данных	Описание
AnswerID	INTEGER	Уникальный идентификатор ответа
AnswerText	TEXT	Текст ответа
QuestionID	INTEGER	Идентификатор вопроса, определяет к какому вопросу соответствует ответ

Поле таблицы	Тип данных	Описание
FormID	INTEGER	Уникальный идентификатор анкеты
QuestionID	INTEGER	Идентификатор вопроса

Таблица Survey содержит опубликованные анкеты по которым в данный момент происходит анкетирование

Поле таблицы	Тип данных	Описание
SurveyID	INTEGER	Уникальный идентификатор ответа
AnswerText	TEXT	Текст ответа
QuestionID	INTEGER	Идентификатор вопроса, определяет к какому вопросу соответствует ответ

Рис. 3.11. Физическая модель данных

Раздел: Информатика, программирование
Количество знаков с пробелами: 97537
Количество таблиц: 15
Количество изображений: 21

В данной работе проектирование происходит в среде MS Access – современная СУБД для персональных компьютеров, исполняющая реляционные базы данных, имеющая объектно-ориентированный алгоритмический язык для работы с информацией, методы визуального программирования и достаточно большие возможности.

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

Рисунок 2 – Физическая модель

Алгоритм трансформации физической модели в базу данных:

1) Создать пустую базу данных Microsoft Office Access 2002-2003;

2) Открыть физическую модель в программе Erwin Data Modeler и выбрать пункт меню Database – Database Connection;

3) В поле Username ввести Admin, а в поле Database ввести путь к пустой базе данных Microsoft Office Access 2002-2003, после чего нажать на кнопку Connect;

4) Выбрать пункт меню Tools – Forward Engineer – Schema Generation;

5) В поле Access 2000/2003 Schema выбрать Table, а в поле Table поставить флажки на пунктах Validation и Generate Table;

6) Нажать на кнопку Generate и дождаться окончания генерации

3.2 Проектирование и разработка БД

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

Большинство используемых сегодня баз данных попадают в категорию реляционных баз данных, которые организуют данные в виде набора связанных таблиц. Хотя данная книга нацелена на изучение именно реляционных баз данных, существуют и другие типы баз. К примеру, большинство старых систем использовали одноуровневые неструктурированные базы данных, в которых данные были расположены в одной большой таблице. Также существуют объектно-ориентированные, иерархические и сетевые базы данных.

Сетевая модель данных. Сетевая база данных, предназначенная для систем среднего размера, появилась, как способ улучшить иерархическую модель. Название происходит от представления базы данных в виде сети связанных таблиц. По сути, сетевая диаграмма выглядит очень похоже на ERD, которые мы используем в этой книге. Основное различие между сетевой и реляционной базой данных состоит в том, что в реляционной базе данных используются внешние ключи для создания связей между таблицами, тогда как сетевая база данных использует для связи таблиц физические указатели. Это кажущееся небольшим отличие приводит при внедрении баз к сильным различиям между ними. Самый известный сетевой продукт, названный IDMS (Integrated database management systems, интегрированная система управления базами данных) была разработана компанией Computer Associates. Как и IMS, IDMS сложна в использовании, и для взаимодействия с такой базой данных требуется профессиональный программист.

4.Использование средств заполнения БД

Для создания базы данных в Microsoft Access можно использовать два способа. Простейший способ создания базы данных - использование мастера баз данных для создания всех необходимых таблиц, форм и отчетов. Имеется также возможность создать пустую базу данных, а затем добавить в нее таблицы, формы, отчеты и другие объекты - это наиболее гибкий способ, но он требует отдельного определения каждого элемента базы данных. В обоих случаях созданную базу данных можно в любое время изменить и расширить.

Рисунок 3 – Окно база данных

5.Осуществление резервного копирования и восстановления данных

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

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

6. Использование стандартных методов защиты объектов БД

Public Sub TestDAO ()

Dim mWS As DAO. Workspace

Dim mDB As DAO. Databas

Set mWS = DBEngine. Workspaces (0)

Set mDB = mWS. OpenDatabase _

(“C: \a97. mab”, True, True, “;pwd=123”)

Public Sub TestADO ()

Dim CnDB As New ADODB. Connection

CnDB. Open “Provider=Microsoft. Jet. OLEDB. 4. 0”&_

“; data Sourse=C:\a97. mdb”&_

“;Jet OLEDB: Database Password=123”

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

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

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

Список использованных литератур

2. Дунаев В.В. Язык SQL для студента. – СПб.: БХВ, 2007. – 312 с.

4. Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: ДИАЛОГ-МИФИ, 2007. – 432 с.

6. Мартин Грубер. Введние в SQL, БХВ-Петербург, 2006. – 217 с.

7. Мартин Грубер. SQL. Справочное руководство. – М.: Лори, 2006. – 368 с.

Задачи и функции аптечной организации: Аптеки классифицируют на обслуживающие население; они могут быть.

Опасности нашей повседневной жизни: Опасность — возможность возникновения обстоятельств, при которых.

Роль химии в жизни человека: Химия как компонент культуры наполняет содержанием ряд фундаментальных представлений о.

Романтизм как литературное направление: В России романтизм, как литературное направление, впервые появился .

Читайте также: