Российский государственный социальный университет Факультет Инженерно-технический Кафедра кафедра информационных технологий, экологии и экологического права Отчёт О прохождении практики по получению профессиональных умений и опыта профессиональной деятельности Студентом Шуклиной Анной Анатольевной (Ф.И.О.) Факультета инженерно-технического Направления 09.04.01 «Информатика и вычислительная техника» Курса 2 Формы обучения заочной Группы ИВТ-М-1-З-2014-1 в должности практиканта, ООО «Остров» (должность, наименование организации (предприятия)) с «02» февраля 2016 г. по «29» февраля 2016 г. Подпись студента Шуклина А.А (Ф.И.О.) «29» февраля 2016 г. Подпись руководителя практики от организации (предприятия) Жданов Б.А. (Ф.И.О.) «29» февраля 2016 г. . Подпись руководителя практики от Университета Руденко В.В. (Ф.И.О.) «29 » февраля 2016 г. . Отчёт принял Заведующий кафедрой Руденко В.В. (Ф.И.О.) «»2016 г. Рабочие записи практиканта Ая неделя. Дата 02.02.2016 Изучение нормативных документов,регламентирующих условия и режим работы сотрудников: законов и нормативные акты РФ Дата 03.02.2016 Изучение нормативных документов,регламентирующих условия и режим работы сотрудников: законов и нормативные акты РФ Дата 04.02.2016 Изучение структуры рабочего процесса в сети магазинов ООО «Остров» и правил ведения торговли и отчетной документации Дата 05.02.2016 Изучение структуры рабочего процесса в сети магазинов ООО «Остров» и правил ведения торговли и отчетной документации Дата 06.02.2016 Изучение коллективного договора, Корпоративного кодекса ООО «Остров», прочих локальных нормативных актов Дата 07.02.2016 Изучение коллективного договора, Корпоративного кодекса ООО «Остров», прочих локальных нормативных актов Дата 08.02.2016 Изучение программного обеспечения и информационных систем на предприятии. На персональных компьютерах предприятия установлены такие информационные системы как 1C: Предприятие 7.7, Microsoft Office 2010. Ая неделя. Дата 09.02.2016 Разработка слоя бизнес - логики для предприятий, осуществляющих розничную торговлю Для начала разберемся, что же представляет собой эта бизнес-логика. Под этим понятием обычно принимают совокупность некоторых правил, принципов и зависимостей поведения некоторых объектов предметной области. Говоря более простым языком — это реализация правил и ограничений автоматизируемых операций. Так же можно сказать, что это реализация предметной области в информационной системе. В качестве примера рассмотрим сеть магазинов, осуществляющих продажу электроинструментов, крепежа, строительного материала и прочих комплектующих. Основными подразделениями, которые осуществляют деятельность магазина, являются: 1. Бухгалтерия, которая отвечает за расчет и выдачу зарплаты, а так же составление отчетности для налоговых служб; 2. Отдел менеджмента, в свою очередь обеспечивает обновление базы данных и управление магазином; 3. Продавцы отвечают за продажу и консультацию клиентов. Для начала рассмотрим, как происходит учет и реализация продукции на предприятиях. В момент, когда товар продан клиенту, однако он еще не оплачен им, тогда продукция считается отгруженной. Момент времени реализации отгруженной продукции это и есть дата зачисления средств на расчетный счет платежа от клиента. Выход товара происходит через розничную торговлю по средствам свободной продажи. До своего выхода отгруженная продукция учитывается на активном счете предприятия. По дебету счета показывается конечная сумма, которую, в свою очередь, следует оплатить покупателю. Дата 10.02.2016 Реализованный товар обычно учитывается на лицевом счете предприятия. Особенностью этого счета считается вывод данных по дебету и кредиту равного объема проданного товара. По дебету выводятся данные по затратам организации проданного товара, а так же по его производству. Вырученные деньги от проданного товара отражается уже по кредиту счета. Если по дебету происходит повышение оборота. То это приводит к убытку, в противном случае к прибыли. В случае, когда товар выходит на продажу клиенту без предоплаты, тогда операции по учету формируются в следующем порядке: · Учтен готовый товар по его фактической себестоимости; · Продан товар клиенту по фактической себестоимости; · Выведена прейскурантная стоимость тары, которая оплачивается клиентом помимо стоимости товара; · Выведены расходы на транспортировку товаров, которые так же оплачиваются клиентом; · Получена выручка от продажи товара; · Проданный товар списан по фактической себестоимости; · Списана стоимость продукции; · Клиент оплатил затраты на транспортировку; · По проданному товару выведены суммы на налоги и акцизы; · Списаны коммерческие расходы; · Списан исход от продажи. Теперь рассмотрим варианты операций модификации данных. 1. Для добавления нового товара, нового поставщика, нового чека, чека на возврат, а так же данных о поставке следует выполнить следующий алгоритм действий: Проверить существует ли в нужной таблице данные с таким же кодом товара, если да то выйти с кодом ошибки 0, если нет, то добавить новую строку с данными в таблицу и отправить значения выходных параметров на выход с кодом 1. 2. Для внесения изменений в таблицы базы данных, существует следующий алгоритм действий: Проверить существуют ли в таблице данные с таким же кодом, если да, то изменить нужные поля и занести их в таблицу, если нет, то выйти с кодом ошибки - 0. В случае, кода нужно внести изменения в сам код товара, код поставщика или в код чека, который, в свою очередь, является первичным ключом, тогда следует выполнить следующие действия: проверить существует ли в таблице данные с таким же кодом, если да, то отредактировать данные и сохранить, в противном случае изменить номер карты на новый и занести изменения в таблицу. 3. Для удаления данных из таблиц следует выполнить следующий алгоритм действий: проверить существует ли в таблице данные с таким же кодом, если да, то удалить строку данными, если нет, то выйти с кодом ошибки 0. Структура таблиц информационной базы данных, все связи и сущности отображены на схеме ниже. В ее состав входят 6 таблиц, взаимосвязанных друг с другом.  Рис.1. Структура информационной базы данных. После всего вышеперечисленного можно сделать вывод, что разработка слоя бизнес – логики является немаловажной частью любого продукта, будь то автоматизированная информационная система или программное обеспечение. Продумав все возможные процессы работы человека и системы, установленной на машине предприятия в совокупности, можно избежать большинства ошибок и сбоев системы, всяческих взломов и несанкционированного входа в систему. Дата 11.02.2016 Преимущества и недостатки СУБД Firebird На сегодняшнее время в нашей стране в области баз данных смело можно выделить СУБД SQL Server, выпущенную компанией Microsoft. Так как данную СУБД действительно можно назвать достаточно удобной для разработки. Она может удовлетворить многие потребности современного бизнеса. Однако, не смотря на такую популярность SQL Server в России, огромное количество программистов пользуются Firebird. По всему миру насчитывается миллионы программ, которые используют в качестве базы данных Firebird. Поэтому можно сказать, что Firebird обладает немалым количеством преимуществ перед SQL Server. Рассмотрим некоторые из них. В работе с базами данных чаще всего нуждаются предприятия, занимающиеся торговлей, которые ведут учет и реализацию продукции. И компании разрабатывающие системы автоматизации для таких предприятий постоянно прибывают в состоянии конкуренции, так как из-за большого спроса на такие системы, насчитывается огромное количество организаций, выпускающих автоматизированные системы по учету и реализации продукции. Однако большинство заказчиков стремятся купить более дешевый продукт, а так как SQL Server является платным продуктом, то Firebird здесь более выигрышный вариант. Но дело даже не в цене данной СУБД, все разработчики стремятся, что бы их продукт работал на любом железе, а SQL Server на слабом, относительно устаревшем компьютере показывает слабые результаты. Так же можно отметить, что во время работы SQL Server занимает все допустимое место в оперативной памяти, и не освобождает ее, пока другим приложениям не потребуется место. Это может быть связано с кластерными индексами. SQL Server так же как и остальные СУБД стремиться держать свои индексы в ОЗУ, в целях ускорения выполнения запросов, но так как страницы с данными входят в состав индексов, получается, что вся база данных загружается в ОЗУ. Однако в Firebird первичный ключ, в свою очередь, не является кластерным, следовательно, много оперативной памяти не занимается. Объем той памяти, которую может занять база данных, регулируется через файл конфигурации, который не мешает работе других приложений, работающих в данный момент. Вечный спор разработчиков, что лучше многоверсионная или блокировочная база данных. Нельзя однозначно ответить на этот вопрос. Firebird является многоверсионной базой данных. То есть если запись в данный момент времени изменяется оператором, то она все равно открыта для чтения для другого оператора, то есть читатель и писатель не блокируют друг друга при одновременном использовании одной и той же записи. SQL Server же, в свою очередь, относится к блокировочным базам данных. То есть если один пользователь открыл окно добавления записи в таблицу и изменив данные не сохранил изменения и отошел от компьютера на какое то время, то другой пользователь уже не может прочитать эту таблицу. Вместо того что бы открыть таблицу база данных зависает и пока первый пользователь не сохранит изменения у второго окно с таблицей так и не откроется. Что является не всегда удобным. Конечно, при работе с Firebird тоже возникает потребность во временной блокировке. В этом случае создается новая версия записи, которая, в свою очередь и блокируется, однако операция чтения старой записи не блокируется. В работе с любой базой данных всегда может возникнуть потребность во внесении изменений в уже существующую запись. Если к примеру информация была введена неверно и нужно изменить данные то в Firebird можно просто откатить транзакцию Дата 12.02.2016 В СУБД Firebird есть только 2 уровня изоляции транзакции. Это Snapshot, что означает мгновенный снимок внесенных изменений, и Read committed, что означает невоспроизводимое чтение внесенных изменений. В первом случае транзакция может увидеть все зафиксированные изменения в момент начала своей работы и изменения, проделанные в пределах данной транзакции. Во втором случае транзакция видит все изменения, и свои, и чужие, не смотря на то, были ли они во время начала ее работы или нет. На мой взгляд, этих 2 вида транзакция достаточно для удобной работы и решения поставленных задач. Оба эти уровня достаточно недорого обходятся для данной СУБД. В SQL Server дела с уровнями транзакций обстоят немного по-иному. Здесь их изначально было 4, а именно: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE и относительно с недавних пор был реализован уровень Snapshot и имитация много версионности. Однако работа с этим новым уровнем требует еще больше памяти и ресурсов процессора, и для разработчиков требуются навыки для работы с эти уровнем изоляции. Однако следует отметить, что Firebird не обладает журналом транзакций. Многие разработчики убеждены, что база данных, у которой нет этого журнала, нельзя назвать серьезной СУБД. Однако если подробнее разобраться в работе транзакций, то этот недостаток может стать достоинством. Каждая модификация в БД Firebird может осуществляться в пределах работающей транзакции. У любой транзакции есть свой порядковый номер, называемый TID, и любая запись в БД отмечается также. В том случае, когда транзакция подтверждается, поле с этим TID будет открыта для последующих операций. Однако когда транзакция не подтверждается, то записанное поле будет недоступно. То есть можно сделать вывод, что Firebird не обращается к жесткому диску без особой необходимости. Так же можно отметить, что размер файла базы данных Firebird в разы меньше, чем размер БД SQL Server, включающий в себя такое же количество информации. Плюс следует учесть, что SQL Server обладает журнал транзакций, который чаще всего весит больше, чем сама база данных. Исходя из вышеперечисленного, можно сделать следующий вывод: Конечно в сравнении с Firebird СУБД SQL Server обладает рядом преимуществ, например такими как встроенная репликация и генератор отчетов, Выборка информации из множества других баз данных, хранящихся на одном сервере, поиск в Blob – полях, встроенные в систему средства шифрования. Однако, несмотря на все вышеперечисленные достоинства SQL Server у СУБД Firebird тоже достаточно преимуществ, а именно: · Firebird является абсолютно бесплатным продуктом и достаточно доступным. · Поддержка работы достаточно большого количества пользователей · Кроссплатформенность. · Исходный код открыт · Наличие достаточно удобного инструмента для администрирования, а именно IBExpert, который тоже является бесплатным и легкодоступным продуктом. · Данная СУБД не сильно требовательна к имеющимся ресурсам Дата 13.02.2016 |