ОТЧЕТ ПО УЧЕБНОЙ ПРАКТИКЕ Введение Учебная практика, это составная часть программы среднего образования, одна из форм учебного процесса на третьем или четвёртом курсе. Смысл её проведения в том, чтобы студенты могли понять, какие задачи они будут выполнять на профильном предприятии. Таким образом она помогает будущим специалистам в приобретении практических знаний. Прохождение учебной практики организуется по утвержденной программе, которая определяет конкретные цели и задачи практики. Цель учебной практики – приобретение первичного профессионального опыта и навыков. Основная часть. 1. Установка и настройка платы сетевого адаптера. Расчет адресации в больших сетях. Установка сетевого адаптера в компьютер Сетевой адаптер – это устройство, отвечающее за передачу и прием пакетов, то есть это «окно», через которое компьютер взаимодействует с другими компьютерами и устройствами сети. Как мы уже знаем, сетевые адаптеры бывают внешние и внутренние, интегрированные в материнскую плату. Внешние сетевые карты изготавливают в виде плат расширения, вставляющихся в слот на материнской плате (наиболее распространены), или устройств, подключаемых к USB-порту. PCI-слот – основной слот, использующийся для подключения устройств такого рода. Он может работать на частотах 33 и 66 МГц и согласно спецификациям в широком диапазоне скоростей начиная с 132 Мбайт/с и заканчивая 528 Мбайт/с, чего вполне достаточно для работы в любой сети, будь то 10 Мбит/с или 1000 Мбит/с. В последнее время практически все материнские платы имеют интегрированный сетевой адаптер, что достаточно удобно и к тому же позволяет сэкономить немного денег. Однако большинство встроенных сетевых плат – невысокого уровня, что не позволяет использовать их для организации работы серверов и других функциональных компьютеров. Поэтому многие предпочитают устанавливать дополнительную сетевую карту. Для установки сетевого адаптера в компьютер нужно снять с системного блока прикрывающую его образную крышку (или левую боковину), открутив сзади корпуса несколько винтов. Выбрав PCI-слот, в который планируется установить сетевую карту, следует открутить или выломать соответствующую планку в задней стенке корпуса. Перед тем как выкручивать и тем более выламывать планку, приложим сетевую карту к PCI-слоту, чтобы определить, какую из прорезей на задней стенке корпуса нужно освободить. Сетевые карты могут быть как в левом исполнении, когда сама плата находится слева от слота, так и в правом. От этого зависит, какую из планок нужно снимать. После этого возьмем сетевую плату так, чтобы металлическая планка оказалась повернутой в сторону, противоположную от компьютера, и несильным, но настойчивым нажатием на плату с двух сторон вставим ее в слот. Теперь можно установить крышку корпуса обратно и подключить к выходу сетевой карты кабель или (при использовании беспроводной сетевой карты) прикрутить антенну. Установив сетевой адаптер, можно включить компьютер и заняться установкой и настройкой драйверов. 2. Настройка межсетевого взаимодействия и устранение ошибок в локальных сетях. Настройка межсетевого взаимодействия и устранение ошибок в глобальных сетях. В глобальных сетях связь между ЛВС осуществляется посредством так называемых мостов. Мосты представляют собой программно-аппаратные комплексы, которые соединяют ЛВС между собой, а также ЛВС и удаленные рабочие станции (PC), позволяя им взаимодействовать друг с другом для расширения возможностей сбора и обмена информацией. Мост обычно определяется как соединение между двумя сетями, которые используют одинаковый протокол взаимодействия, одинаковый тип среды передачи и одинаковую структуру адресации. Тип мостов: • внутренний/внешний; • выделенный/совмещенный; • локальный/удаленный. Внутренний — мост располагается на файловом сервере. Внешний — на рабочей станции. Внешние мосты и их ПО устанавливаются в рабочей станции, которая не загружена функциями файлового сервера. Поэтому внешний мост может передавать данные более эффективно, чем внутренний. Выделенный мост — это ПК, который используется только как мост и не может функционировать как рабочая станция. Совмещенный — может функционировать и как мост, и как рабочая станция одновременно. Преимущество: ограничиваются издержки на покупку дополнительного компьютера. Недостаток: ограничение возможностей рабочей станции, совмещенной с мостом. Локальный мост передает данные между сетями, которые расположены в пределах ограничений кабеля по расстоянию. Локальные мосты применяются в следующих случаях: • разделение больших сетей на подсети с целью увеличения быстродействия и уменьшения стоимости линий связи. Например, в одной организации различные отделы используют одну и ту же сеть. Пример разделения большой сети медленнее малых, есть возможность выделить в небольшие подсети компактно расположенные отделы. Используя локальный мост, отделы могут продолжать использовать данные таким образом, как если бы они работали в одной сети, приобретая при этом быстродействие и гибкость, присущие малой сети; • расширение физических возможностей сети. Если сеть имеет максимально допустимое число узлов, поддерживаемое аппаратной схемой адресации, и есть необходимость в добавлении еще нескольких узлов, то для расширения такой сети используется мост. При этом возможно включение в сеть дополнительного файл-сервера; • объединение сетей в интерсеть. Чтобы пользователи каждой сети могли получить доступ к информации других сетей, необходимо связать эти сети, образуя интерсеть. Расширение физических возможностей сети. Удаленные мосты применяются, когда расстояние не позволяет соединять сети посредством кабеля, если ограничение по длине кабеля для локального моста будет превышено. Удаленный мост использует промежуточную среду передачи (телефонные линии) для соединения с удаленной сетью или удаленными Пример интерсети. PC. При связи сети с удаленной сетью необходимо установить мост на каждом конце соединения, а при связи сети с удаленным PC требуется только сетевой мост. 3. Создание концептуальной, логической и физической модели данных. Известно и чаще всего встречается три вида моделей данных и соответственно три способа моделирования данных. Каждый способ моделирования отражает строго один определённый аспект данных, где аспекты (внимание!) — это темпоральные стадии процесса проектирования (процесс "от замысла до воплощения") некой системы, управляющей данными. Здесь данные — это [не строго] некоторый конгломерат информации об окружающем нас мире, имеющий ценность для пользователя/потребителя этой информации. Каждый из способов моделирования порождает свою модель, где модель — это множество элементов, образующих слой данных определенного уровня абстрактности или детальности: Концептуальный - концептуальная модель. Цель модели - установить семантику (дать определение, установить смыслы) моделируемых явлений реальности и их информационные взаимосвязи. Логический - логическая модель. Цель модели - логически выверенный, оптимизированный и нормализованный набор атрибутов, характеризующих данные, а также связанные с данными методы их обработки. Логический уровень являет собой также спецификацию на реализацию данных в определенной выбранной технологии. Более строго за логическом уровнем следует уровень спецификации и уровень конфигурации данных, о чем хорошо знают сторонники ООП. Физический - физическая модель. Программное воплощение структур данных. Собственно данные - модель реальности, выраженная в символьно-числовом виде. То есть это уже не модель данных, а отражение реальности в конкретных экземплярах, внесенных в физическую модель. три слоя — это темпоральные стадии одной и той же атомарной единицы единицы данных. В таком случае концептуальный уровень задаёт смысловой объем понятия, заключенного в единице данных, логический - описывает спецификацию единицы данных, физический - описывает реализацию единицы данных. Концептуальный слой моделирования. В концептуальном слое моделирования (или на концептуальном уровне моделирования) мы определяем основные понятия предметной области и их взаимосвязь. Иногда также используют термин "построение онтологиии предметной области". В сущности — это семантическая модель предметной области или одного из её доменов. Примеры концептов или бизнес-сущностей: клиент (как вариант, клиент-ФЛ, клиент-ЮЛ) - это … <далее идет попытка вербально определить основные характеристики, позволяющие отнести наблюдаемое явление к тому, что обозначается словом клиент> продукт (как вариант, товар, услуга) — это <... ... ...> сделка (как вариант, заказ) — это <... ... ...> контракт — это <... ... ...>. Логический уровень. Логический уровень моделирования – это уровень логики организации данных, то есть какие данные и как сгруппированы и связаны друг с другом. Концептуальный уровень больше заботится о смысловых связях, логический – о реальных связях между объектами системы (ссылки объектов друг на друга, отношения объектов). Концептуальный уровень оперирует бизнессущностями, логический – сущностями будущей или фактически имеющейся информационной системы (например, базы данных). В компаниях с большой историей логический уровень задан фактически развернутыми системами конкретных вендоров. Слово "логический" стоит понимать в смысле "строго выверенный по правилам математической логики". Примеры сущностей (классов): клиент - party + customer + customer_profile + person продукт - продукт + предложение продукта + price plan заказ - order, order_item Физический уровень или слой моделирования Физический слой – это слой таблиц для реляционных моделей данных. С точки зрения ИТ — это слой наивысшей детализации данных. Инвентаризация данных на этом уровне в корпоративном масштабе крайне затруднительна: для одной-двух-двадцати систем это можно сделать вручную. Если систем десятки и сотни, то такую инвентаризацию нужно делать автоматически путем автоматизированного сбора метаданных. Или отказаться от идеи инвентаризации физических структур данных в репозитории, ограничившись лишь ведением логической модели данных эксплуатируемых/развиваемых приложений. Физические модели в таком случае остаются описанными лишь в документации на системы и задача ведения репозитория - задача ведения реестра системной документации. Базовый элемент физической модели: таблица. Примеры таблиц: клиент - table_1 продукт - table_2 сделка - table_3 4. Работы с объектами базы данных в конкретной системе управления базами данных. С базами данных работают две категории исполнителей. Первая категория — проектировщики. Их задача состоит в разработке структуры таблиц 6aз данных и согласовании ее с заказчиком. Кроме таблиц проектировщики разрабатывают и другие объекты базы данных, предназначенные, с одной стороны, для автоматизации работы с базой, а с другой стороны — для ограничения функциональных возможностей работы с базой (если это необходимо из соображений безопасности). Вторая категория исполнителей, работающих с базами данных, — пользователи. Они получают исходную базу данных от проектировщиков и занимаются ее наполнением и обслуживанием. В общем случае пользователи не имеют средств доступа к управлению структурой базы — только к данным. Соответственно, система управления базами данных имеет два режима работы, проектировочный и пользовательский. Первый режим предназначен для создания или изменения структуры базы и создания ее объектов. Во втором режиме происходит использование ранее подготовленных объектов для наполнения базы или получения данных из нее. Microsoft Access позволяет создавать и использовать объекты семи различных типов. Таблиц — это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства). Запросы. Эти объекты служат для извлечения данных из таблиц и предоставления их пользователю в удобном виде. С помощью запросов выполняют такие операции, как отбор данных, их сортировку и фильтрацию. С помощью запросов можно выполнять преобразование данных по заданному алгоритму, создавать новые таблицы, выполнять автоматическое наполнение таблиц данными, импортированными из других источников, выполнять простейшие вычисления в таблицах и многое другое. Особенность запросов состоит в том, что они черпают данные из базовых таблиц и создают на их основе временную результирующую таблицу. Если хотят подчеркнуть факт «временности» этой таблицы, то ее еще называют моментальным снимком. Когда мы работаем с основными таблицами базы, мы физически имеем дело с жестким диском, то есть с очень медленным устройством (напомним, что это связано с особенностью сохранения данных, рассмотренной выше). Когда же на основании запроса мы получаем результирующую таблицу, то имеем дело с электронной таблицей, не имеющей аналога на жестком диске, — это только образ отобранных полей и записей. Разумеется, работа с «образом» происходит гораздо быстрее и эффективнее — это еще одно основание для того, чтобы широко использовать запросы. Формы — это средства для ввода данных, хотя с их помощью данные можно и просматривать. Смысл их в том, чтобы предоставить пользователю средства для заполнения только тех полей, которые ему заполнять положено. Одновременно с этим в форме можно разместить специальные элементы управления (счетчики, раскрывающиеся списки, переключатели, флажки и прочие) для автоматизации ввода. Отчеты - предназначены только для вывода данных, причем для вывода не на экран, а на печатающее устройство (например, принтер), В связи с этим, отчеты отличаются тем, что в них приняты специальные меры для группирования выводимых данных и для вывода специальных элементов оформления, характерных для печатных документов (верхний и нижний колонтитулы, номера страниц, служебная информация о времени создания отчета и т п.). Страницы. Это специальные объекты баз данных, более корректно их называть страницами доступа к данным. Физически это особый объект, выполненный в коде HTML, размещаемый на Web-странице и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данных, но содержит компоненты, через которые осуществляется связь переданной Webстраницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель Web-узла может просматривать записи базы в полях страницы доступа. Таким образом, страницы доступа к данным осуществляют интерфейс между клиентом, сервером и базой данных, размешенной на сервере. Макросы и модули. Эти категории объектов предназначены как для автоматизации повторяющихся операций при работе с системой управления базами данных, так и для создания новых функций путем программирования. В СУБД Microsoft Access макросы состоят из последовательности внутренних команд СУБД и являются одним из средств автоматизации работы с базой. Модули создаются средствами внешнего языка программирования, в данном случае языка Visual Basic for Applications. Это одно из средств, с помощью которых разработчик базы может заложить в нее нестандартные функциональные возможности, удовлетворить специфические требования заказчика, повысить быстродействие системы управления, а также уровень ее защищенности. 5. Использование средств заполнения базы данных Перед созданием базы данных разработчик должен определить, из каких таблиц должна состоять база данных, какие данные нужно поместить в каждую таблицу, как связать таблицы. Эти вопросы решаются на этапе проектирования базы данных. В результате проектирования должна быть определена логическая структура базы данных, то есть состав реляционных таблиц, их структура и межтабличные связи. Перед созданием базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, определить все необходимые источники информации для удовлетворения предполагаемых запросов пользователей и определить потребности в обработке данных. На основе такого описания на этапе проектирования базы данных определяются состав и структура данных предметной области, которые должны находиться в БД и обеспечивать выполнение необходимых запросов и задач пользователей. Структура данных предметной области может отображаться информационно-логической моделью. На основе этой модели легко создается реляционная база данных. Этапы проектирования и создания базы данных определяются следующей последовательностью: • построение информационно-логической модели данных предметной области; • определение логической структуры реляционной базы данных; • конструирование таблиц базы данных; • создание схемы данных; • ввод данных в таблицы (создание записей); • разработка необходимых форм, запросов, макросов, модулей, отчетов; • разработка пользовательского интерфейса. В процессе разработки модели данных необходимо выделить информационные объекты, соответствующие требованиям нормализации данных, и определить связи между ними. Эта модель позволяет создать реляционную базу данных без дублирования, в которой обеспечивается однократный ввод данных при первоначальной загрузке и корректировках, а также целостность данных при внесении изменений. При разработке модели данных могут использоваться два подхода. В первом подходе сначала определяются основные задачи, для решения которых строится база, выявляются потребности задач в данных и соответственно определяются состав и структура информационных объектов. При втором подходе сразу устанавливаются типовые объекты предметной области. Наиболее рационально сочетание обоих подходов. Это связано с тем, что на начальном этапе, как правило, нет исчерпывающих сведений обо всех задачах. Использование такой технологии тем более оправдано, что гибкие средства создания реляционных баз данных позволяют на любом этапе разработки внести изменения в базу данных и модифицировать ее структуру без ущерба для введенных ранее данных. Процесс выделения информационных объектов предметной области, отвечающих требованиям нормализации, может производиться на основе интуитивного или формального подхода. Теоретические основы формального подхода были разработаны и полно изложены в монографиях по организации баз данных известного американского ученого Дж. Мартина. При интуитивном подходе легко могут быть выявлены информационные объекты, соответствующие реальным объектам. Однако получаемая при этом информационно-логическая модель, как правило, требует дальнейших преобразований, в частности преобразования много-многозначных связей между объектами. При таком подходе возможны существенные ошибки, если отсутствует достаточный опыт. Последующая проверка выполнения требований нормализации обычно показывает необходимость уточнения информационных объектов. Рассмотрим формальные правила, которые могут быть использованы для выделения информационных объектов. • на основе описания предметной области выявить документы и их атрибуты, подлежащие хранению в базе данных; • определить функциональные зависимости между атрибутами; • выбрать все зависимые атрибуты и указать для каждого все его ключевые атрибуты, т. е. те, от которых он зависит; • сгруппировать атрибуты, одинаково зависимые от ключевых атрибутов. Полученные группы зависимых атрибутов вместе с их ключевыми атрибутами образуют информационные объекты. При определении логической структуры реляционной базы данных на основе модели каждый информационный объект адекватно отображается реляционной таблицей, а связи между таблицами соответствуют связям между информационными объектами. В процессе создания сначала конструируются таблицы базы данных, соответствующие информационным объектам построенной модели данных. Далее может создаваться схема данных, в которой фиксируются существующие логические связи между таблицами. Эти связи соответствуют связям информационных объектов. В схеме данных могут быть заданы параметры поддержания целостности базы данных, если модель данных была разработана в соответствии с требованиями нормализации. Целостность данных означает, что в БД установлены и корректно поддерживаются взаимосвязи между записями разных таблиц при загрузке, добавлении и удалении записей в связанных таблицах, а также при изменении значений ключевых полей. После формирования схемы данных осуществляется ввод непротиворечивых данных из документов предметной области. На основе созданной базы данных формируются необходимые запросы, формы, макросы, модули, отчеты, производящие требуемую обработку данных базы и их представление. С помощью встроенных средств и инструментов базы данных создается пользовательский интерфейс, позволяющий управлять процессами ввода, хранения, обработки, обновления и представления информации базы данных. 6. Использование стандартных методов защиты объектов базы данных. Средства защиты БД в различных СУБД несколько отличаются друг от друга. На основе анализа современных СУБД Borland и Microsoft можно утверждать, что средства защиты БД условно делятся на две группы, основные и дополнительные. К основным средствам защиты информации можно отнести следующие средства: - парольная защита; - шифрование данных и программ; - установление прав доступа к объектам БД; - защита полей и записей таблиц БД. Парольная защита представляет простой и эффективный способ защиты БД от несанкционированного доступа. Пароли устанавливаются конечными пользователями или администраторами БД. Учет и хранение паролей производится самой СУБД. Обычно пароли хранятся в определенных системных файлах СУБД в зашифрованном виде. Поэтому просто найти и определить пароль невозможно. После ввода пароля пользователю СУБД предоставляются все возможности по работе с защищенной БД. Шифрование данных (всей базы или отдельных таблиц) применяется для того, чтобы другие программы не могли прочитать данные. Шифрование исходных текстов программ позволяет скрыть от несанкционированного пользователя описание соответствующих алгоритмов. В целях контроля использования основных ресурсов СУБД во многих системах имеются средства установления прав доступа к объектам БД. Права доступа определяют возможные действия над объектами. Владелец объекта (пользователь, создавший объект), а также администратор БД имеют все права. Остальные пользователи к разным объектам могут иметь различные уровни доступа. По отношению к таблицам в общем случае могут предусматриваться следующие права доступа. - просмотр (чтение) данных; - изменение (редактирование) данных; - добавление новых записей; - добавление и удаление данных; - все операции, в том числе изменение структуры таблицы. К данным, имеющимся в таблице, могут применяться меры защиты по отношению к отдельным полям и отдельным записям. В реляционных СУБД отдельные записи специально не защищаются. Применительно к защите данных в полях таблиц можно выделить следующие уровни прав доступа: - полный запрет доступа; - только чтение; - разрешение всех операций (просмотр, ввод новых значений, удаление и изменение). По отношению к формам могут предусматриваться две основные операции: вызов для работы и разработка (вызов Конструктора). Запрет вызова Конструктора целесообразно делать для экранных форм готовых приложений, чтобы конечный пользователь случайно не испортил приложение. В самих экранных формах отдельные элементы могут быть тоже защищены. Например, некоторые поля исходной таблицы вообще могут отсутствовать или скрыты от пользователя, а некоторые поля – доступны только для просмотра. Отчеты во многом похожи на экранные формы, за исключением следующего. Во-первых, они не позволяют изменять данные в таблицах, а во-вторых, основное их назначение – вывод информации на печать. На отчеты, так же, как и на экранные формы, может накладываться запрет на вызов средств их разработки. Для исключения просмотра и модификации (случайной или преднамеренной) текстов программ, используемых в приложениях СУБД, помимо шифрации, может применяться их парольная защита. К дополнительным средствам защиты БД можно отнести такие, которые нельзя прямо отнести к средствам защиты, но которые непосредственно влияют на безопасность данных. Это следующие средства: • встроенные средства контроля значений данных в соответствии с типами; • повышения достоверности вводимых данных; • обеспечения целостности связей таблиц; • организации совместного использования объектов БД в сети. Редактируя БД, пользователь может случайно ввести такие значения, которые не соответствуют типу поля, в которое это значение вводится (например, ввод в числовое поле текстовой информации). В этом случае СУБД с помощью средств контроля значений блокирует ввод и сообщает пользователю об ошибке. Средства повышения достоверности вводимых значений в СУБД служат для более глубокого контроля, связанного с семантикой обрабатываемых данных. Они обычно обеспечивают возможность при создании таблицы указывать следующие ограничения на значения: минимальное и максимальное значения, значение, принимаемое по умолчанию (если нет ввода), требование обязательного ввода; задание маски (шаблона) ввода и т.д. Более совершенной формой организации контроля достоверности информации в БД является разработка хранимых процедур. Механизм хранимых процедур применяется в БД, размещенных на сервере. Сами хранимые процедуры представляют собой программы, алгоритмы которых предусматривают выполнение некоторых функций (в том числе контрольных) над данными. Процедуры хранятся вместе с данными и при необходимости вызываются из приложений либо при наступлении некоторых событий в БД. [ Решение прикладной задачи, как правило, требует выбора информации из нескольких таблиц. Таблицы в базе данных могут быть связаны. Функции поддержания логической целостности связанных таблиц берет на себя СУБД. Если СУБД не реализует эти функции, то ответственность за корректность связей возлагается на приложение. Приведем пример возможных действий СУБД по контролю целостности связей таблиц. Пусть между двумя таблицами существует связь вида 1.М и, следовательно, одной записи основной таблицы может соответствовать несколько записей вспомогательной таблицы. При вставке записей во вспомогательную таблицу система контролирует наличие соответствующих значений в поле связи основной таблицы. Если вводимое значение отсутствует в основной таблице, СУБД временно блокирует работу с новой записью и предлагает изменить значение или удалить запись целиком. Удаление записей из дополнительных таблиц не контролируется. При удалении записи из основной таблицы происходит проверка. В случае, когда запись основной таблицы связана с несколькими записями дополнительной таблицы, возможны два варианта поведения. Не удалять основной записи, пока имеется хотя бы одна подчиненная запись (записи должен удалять пользователь), либо удалить основную запись и все подчиненные записи (каскадное удаление). В распределенных информационных системах, работающих с базами данных, возникает проблема разрешения конфликтов между различными действиями над одними и теми же объектами (совместного использования объектов БД). Например, что делать в случае, когда один из пользователей локальной сети редактирует БД, а другой хочет изменить ее структуру? Для таких ситуаций в СУБД должны быть предусмотрены механизмы разрешения конфликтов. Обычно при одновременной работе нескольких пользователей в сети используются блокировки. Блокировки могут действовать на различные объекты БД и на отдельные элементы объектов. Блокировки объектов возникают, когда параллельно с использованием объекта предпринимается попытка входа в режим разработки этого же объекта. Применительно к таблицам баз данных дополнительные блокировки могут возникать при работе с отдельными записями или полями. Блокировки бывают явные и неявные. Явные блокировки накладываются пользователем или приложением с помощью команд. Неявные блокировки организует сама система, чтобы избежать возможных конфликтов. Например, в случае попытки изменения структуры БД во время редактирования информации устанавливается запрет реструктурирования БД до завершения редактирования данных. Заключение Прохождение учебной практики является важным элементом учебного процесса по подготовке специалиста в области программирования. Во время её прохождения будущий программист применяет полученные в процессе обучения знания, умения и навыки на практике. Могу сказать, что за прохождение учебной практики я узнал много нового. Например, что такое сетевой адаптер, как его устанавливать и как его настраивать в больших сетях. А так же, как настраивать и устранять ошибки в локальных и глобальных сетях. Ещё создавали различные модели данных и работали с объектами баз данных через систему управления БД. Мы также использовали средства заполнения базы данных и использовали стандартные методы её защиты. За время практики я получил бесценный опыт. Овладел навыками, которые помогут мне в дальнейшем в учёбе и работе.
