Лабораторная работа по архитектуре База данных. 10842963_Лаб2. база данных по архитектуре. Лабораторная работа 2 базы данных содержание Задание 2 Цели и задачи лабораторной работы 3 Выполнение задания 4
 Скачать 328.01 Kb.
|
|
Лабораторная работа № 2 БАЗЫ ДАННЫХ СодержаниеЗадание 2 Цели и задачи лабораторной работы 3 Выполнение задания 4 Контрольные вопросы 17 ЗаданиеСоставить план разработки проекта базы данных для заданной предметной области. Базу данных следует рассматривать как часть будущей информационной системы, автоматизирующей бизнес-процессы некоторой организации. Выполнить анализ заданной предметной области. Сформулировать словесное описание информационных объек-тов. Описать типовые запросы для поиска и анализа информации об объектах предметной области. Построить концептуальную модель данных, описывающую предметную область в рамках ER-модели «сущность – связь». Получить визуальное представление концептуальной модели путём построения ER-диаграмм. Построить логическую модель базы данных. Преобразовать полученные ранее ER-модели в конкретную схему реляционной базы данных. Проверить полноту и корректность логической модели базы данных путём составления на языке SQL типовых запросов для поиска и анализа информации. 6. Модели, полученные на этапах анализа предметной области, концептуального и логического проектирования, а также результаты составления и проверки типовых запросов оформить в виде общего документа – проекта базы данных Цели и задачи лабораторной работыЦелями выполнения лабораторной работы являются: Закрепление имеющихся знаний о базах данных. Изучение методологии проектирования базы данных как основы информационной системы. Приобретение навыков анализа и формализованного описания заданной предметной области. Приобретение навыков разработки проекта базы данных с учётом её использования в составе некоторой информационной системы. процессе выполнения лабораторной работы решаются следующие задачи: 1. Выполняется системный анализ заданной предметной области. Составляется формализованное описание информационных объектов предметной области. 2. Разрабатывается концептуальная модель базы данных, описывающая сущности предметной области и связи между ними. 3. Выполняется логическое проектирование реляционной базы данных. Составляются типовые запросы на языке SQL для поиска и анализа информации. Выполнение заданияБудем рассматривать автоматизацию деятельности школы. Разрабатываемая база данных будет хранить данные о классах, предметах, учениках и учета оценок в журнале. Школа является учебным заведением, где у учеников определенных классов ведутся определенные предметы. По данным предметам ведется учет успеваемости учеников. На основе описания предметной области были выделены следующие сущности, представленные в таблице 1. Т а б л и ц а 1 – Сущности предметной области
В CA ERwin Data Modeler различают 3 подуровня логического уровня модели данных, отличающиеся по глубине представления информации о данных: 1) ER-диаграмма (Entity Relationship Diagram) – диаграмма «Сущность-связь»; 2) KB-модель (Key Based model) – модель данных, основанная на ключах; 3) FA-модель (Fully Attributed model) – полная атрибутивная модель. На основе данных таблицы 1 была сформирована ER-диаграмма, представленная на рисунке 1.  Рисунок 1 – ER-диаграмма базы данных успеваемости учеников Модель данных, основанная на ключах (KB – модель), кроме сущностей и связей, включает в себя ключевые атрибуты сущностей: первичные (PK) и внешние (FK). Для определения первичных и внешних ключей сущностей в результате анализа предметной области были выявлены следующие основные закономерности: 1. Каждый класс обладает уникальным номером; 2. Каждый класс содержит учеников; 3. Каждый предмет обладает уникальным номером; 4. Каждый предмет фиксируется в журнал; 5. Каждый ученик обладает уникальным номером; 6. Каждый ученик имеет оценки в журнале; 7. Каждый ученик осваивает предметы. Зададим атрибуты для сущностей Для сущности Klass в качестве атрибутов будут следующие: IdKlass (идентификационный номер); NameKlass (название класса). Для сущности Ucheniki в качестве атрибутов будут следующие: IdU (идентификационный номер ученика); FirstName (фамилия); LastName (имя); Klass (класс). Для сущности Predmet в качестве атрибутов будут следующие: IdPred (идентификационный номер предмета); Predmet (предмет). Для сущности Jurnal в качестве атрибутов будут следующие: IdJurnal (идентификационный номер); Uchenik (ученик); Predmet (предмет); Ocenka (оценка). Для каждой сущности были определены первичные ключи, на основе следующих требований: атрибуты первичного ключа не могут принимать неопределенных значений; атрибуты первичного ключа должны однозначно идентифицировать экземпляр сущности; количество атрибутов в первичном ключе должно быть минимальным. В результате была сформирована KB-модель, которая представлена на рисунке 2  Рисунок 2 – KB-модель базы данных учета успеваемости В таблице 2 отображены атрибуты выявленных ранее сущностей и их описание. Основные функциональные зависимости отражены в таблице 3. Т а б л и ц а 2 – Атрибуты сущностей
Таблица 3 – Функциональная зависимость
В результате на логическом уровне представления данных была сформирована FA-модель предметной области, представленная на рисунке 3.  Рисунок 3 – FA-модель базы данных учета успеваемости Физическая модель данных, в отличие от логического, ориентирована на конкретную СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Для построения трансформационной модели необходимо определить домены атрибутов сущностей, области их допустимых значений, а также типы данных. В таблице 4 отображены необходимые данные и примеры значений, используемые в базе данных. Домены определены в таблице 5. Т а б л и ц а 4 – Домены атрибутов сущностей
Т а б л и ц а 5 – Поля таблиц, их описание и домены
В результате была сформирована трансформационная модель, ориентированная на формат выбранной СУБД и включающая все сущности, атрибуты, их типы данных, ограничения контроля целостности и согласованности. Результат представлен на рисунке 4.  Рисунок 4 – Т-модель базы данных учета успеваемости Далее была разработана DBMS-модель в виде SQL-кода, представленного в приложении А. Его реализация позволила сформировать и построить системный каталог БД MS SQL Server. Реализация модели данных будет происходить по средству передачи (в режиме прямого проектирования) автоматизированной информационной системы учета успеваемости в СУБД MS SQL Server 2014 (и выше). На основе разработанной в CA ERWin DM физической модели данных выполним автоматическую генерацию системного каталога базы данных учета успеваемости на сервере SQL Server 2014. Здесь особенностью является то, что до осуществления передачи модели базы данных из CA ERWin DM на сервер там должна существовать (быть заранее созданной) пустая база данных. Процесс создания такой пустой базы данных с именем «школаSQL» показан на рисунках 5,6. При создании базы вводим только ее название, остальные параметры оставляем «по умолчанию». Процесс создания пустой БД.  Рисунок 5 – Создание базы данных БД Процесс генерации схемы базы данных из модели данных называется прямым проектированием (Forward Engineering). При генерации схемы AllFusion ERwin Data Modeler создает триггеры ссылочной целостности, хранимые процедуры, индексы, ограничения и другие объекты, доступные для выбранной СУБД.  Рисунок 6 – База данных школаSQL Для генерации системного каталога базы данных нужно выполнить команду Tools → Forward Engineer → Schema Generation (рисунок 7). Процесс создания и генерации схемы представлен на рисунках 7-8. В результате чего мы получим SQL-скрипт.  Рисунок 7 – Переход к генерации схемы Рисунок 8 – Успешная проверка данных на SQL Server На основе полученных таблиц создадим диаграмму базы данных в SQL Server 2014. Результат выполнения представлен на рисунке 9.  Рисунок 9 – Создание диаграммы базы данных в SQL Server 2014 Физическое проектирование БД приводит к созданию набора SQL запросов, достаточного, чтобы полностью сформировать базу данных на соответствующей СУБД. Приведем полный список запросов, которые создают базу данных. Создание таблицы «Klass» CREATE TABLE public."Klass" ( "IdKlass" integer NOT NULL DEFAULT nextval('"Klass_IdKlass_seq"'::regclass), "NameKlass" character varying(5) COLLATE pg_catalog."default", CONSTRAINT "Klass_pkey" PRIMARY KEY ("IdKlass") ) WITH ( OIDS = FALSE ) TABLESPACE pg_default; ALTER TABLE public."Klass" OWNER to postgres; Создание таблицы «Ucheniki» CREATE TABLE public."Ucheniki" ( "IdU" integer NOT NULL DEFAULT nextval('"Ucheniki_IdU_seq"'::regclass), "FirstName" character varying(30) COLLATE pg_catalog."default", "LastName" character varying(30) COLLATE pg_catalog."default", "Klass" integer, CONSTRAINT "Ucheniki_pkey" PRIMARY KEY ("IdU"), CONSTRAINT "Klass" FOREIGN KEY ("Klass") REFERENCES public."Klass" ("IdKlass") MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION NOT VALID ) WITH ( OIDS = FALSE ) TABLESPACE pg_default; ALTER TABLE public."Ucheniki" OWNER to postgres; Создание таблицы «Predmet» CREATE TABLE public."Predmet" ( "IdPred" integer NOT NULL DEFAULT nextval('"Predmet_IdPred_seq"'::regclass), "Predmet" character varying(30) COLLATE pg_catalog."default", CONSTRAINT "Predmet_pkey" PRIMARY KEY ("IdPred") ) WITH ( OIDS = FALSE ) TABLESPACE pg_default; ALTER TABLE public."Predmet" OWNER to postgres; Создание таблицы «Jurnal» CREATE TABLE public."Predmet" ( "IdPred" integer NOT NULL DEFAULT nextval('"Predmet_IdPred_seq"'::regclass), "Predmet" character varying(30) COLLATE pg_catalog."default", CONSTRAINT "Predmet_pkey" PRIMARY KEY ("IdPred") ) WITH ( OIDS = FALSE ) TABLESPACE pg_default; ALTER TABLE public."Predmet" OWNER to postgres; Приведем примеры запросов на заполнение БД: Заполнение таблицы «Klass» INSERT INTO public."Klass"( "IdKlass", "NameKlass") VALUES (1, 9); Заполнение таблицы «Ucheniki» INSERT INTO public."Ucheniki"( "IdU", "FirstName", "LastName", "Klass") VALUES (1, 'Иванов', 'Иван', 1); Заполнение таблицы «Predmet» INSERT INTO public."Predmet"( "IdPred", "Predmet") VALUES (1, 'математика'); Заполнение таблицы «Jurnal» INSERT INTO public."Jurnal"( "IdJurnal", "Uchenik", "Predmet", "Ocenka") VALUES (1, 1, 1, 5); Вывод данных таблицы «Klass» (рис. 10). SELECT * FROM public."Klass"  Рисунок 10 - Таблица «Klass» Вывод данных таблицы «Ucheniki» (рис. 11). SELECT * FROM public."Ucheniki"  Рисунок 11 - Таблица «Ucheniki» Вывод данных таблицы «Predmet» (рис. 12). SELECT * FROM public."Predmet"  Рисунок 12 - Таблица «Predmet» Вывод данных таблицы «Jurnal» (рис. 13). SELECT * FROM public."Jurnal"  Рисунок 13 - Таблица «Jurnal» Контрольные вопросыОтветы: Архитектура информационной системы – определение составных частей приложения и способов взаимодействия между ними Клиент-серверные и многоуровневые информационные системы – В данном случае речь идет о системах, в которых основная деятельность состоит из обработки клиентских запросов, а значит, механизмы обработки запроса приводятся в действие путем вызова методов программного кода приложения из обработчиков. Например метод который имеет перегруженную версию для GET и POST запроса. Многоуровневые системы – предполагают разделение частей по функционалу. Программный слой для работы с базой данных, программный слой для работы с запросами и наконец для предоставления пользователю результата в виде HTML страницы. Модели данных представляют собой объекты, который будут хранить данные в приложении. Как правило при создании БД мы создаем таблицы, которые отражают свойства моделей. База данных — совместно используемый набор логически связанных данных , которые используются в приложении. Системы управления базами данных. – программные комплексы, которые обеспечивают работу с базами данных Реляционные базы данных представляют собой базы данных, которые используются для хранения и предоставления доступа к взаимосвязанным элементам информации. Реляционные базы данных основаны на реляционной модели — интуитивно понятном, наглядном табличном способе представления данных. Каждая строка, содержащая в таблице такой базы данных, представляет собой запись с уникальным идентификатором, который называют ключом. Столбцы таблицы имеют атрибуты данных, а каждая запись обычно содержит значение для каждого атрибута, что дает возможность легко устанавливать взаимосвязь между элементами данных. Технологии проектирования баз данных – как правило из приложения выделяются основные компоненты, поля которых будут изменятся, далее выстраивается логическая цепь взаимоотношений между объектами. После чего в базе данных создаются таблицы, которые отражают данные объекты, то есть столбцы таблицы содержат информацию, соответствующую полям объекта. Если в приложении есть необходимость сохранения информации, то в данном случае при разработке выделяется программная часть, которая будет обеспечивать доступ к БД. В этом случае мы определяем способ соединения с БД. Далее мы посылаем SQL запросы на сервер к базе данных, где происходит Создание/Изменение/Удаление/Отображение информации в БД. Приложение может трансформировать запросы посредством фреймворков или адаптеров, либо посылать “чистый” SQL, и преобразовывать результаты запросов к нужным объектам для последующей работы. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||